luup.io.write('XXX')

Developer's Corner General Dev Discussions
1

Hi,

I try to understand the luup.io.write() using a serial port. If I do luup.io.write(‘XXX’) will this send “XXX\r\n”. I assumed it will just send XXX using the raw but there seems to arrive more at the other device I try to control. Any hints? I am new to this, so might be a silly question.

2

Using raw, only the bytes you ask to send are sent. Something else is happening here, so you will have to provide more detail.

3

I try to talk to a PIC microcontroller. The program I put on the PIC looks for a string terminated with a \r. If I just use luup.io.write(‘XXX’) the PIC gets the line (Thus, I assume luup.io.write appends some characters; at least the \r). However, when I send the next command the PIC does not get it anymore (I assume the previous command was terminated with more than just \r). So, I either need to fix my luup code or the c code on the microcontroller.

If raw sends only the bytes (I just wanted to check) then something else is going on. I will debug a bit more and report back when solved (will have time next week to look at it again).

4

[quote=“utz, post:3, topic:168501”]I try to talk to a PIC microcontroller. The program I put on the PIC looks for a string terminated with a \r. If I just use luup.io.write(‘XXX’) the PIC gets the line (Thus, I assume luup.io.write appends some characters; at least the \r). However, when I send the next command the PIC does not get it anymore (I assume the previous command was terminated with more than just \r). So, I either need to fix my luup code or the c code on the microcontroller.

If raw sends only the bytes (I just wanted to check) then something else is going on. I will debug a bit more and report back when solved (will have time next week to look at it again).[/quote]
Sounds like an interesting project…I used to program PIC’s myself.
I would tap into the serial output using an inline breakout box, take the output line from Vera and monitor it with a terminal program that displays HEX. This will save you hours of time wasted on guessing what is going on!
If you have Vera dumping data then just run it straight into a terminal program in the HEX mode.
Tim

5

Yeah, I know what you mean. I came up against a similar dilemma writing a plugin to talk to an Arduino I’d programmed. I concluded that it was easier for me to change the code on the Arduino. (In the end, I ditched the serial interface entirely and stuck an Ethernet shield onto the Arduino. Vera speaks IPv4 better than it speaks serial, IMO.)

I’m reasonably sure (but I wouldn’t put money on it) that the serial driver is not playing shenanigans with the data, such as convertng carriage returns to line feeds.

If you do decide to use raw mode in your Luup plugin, take a look at my Caddx Security plugin for an example. It builds up received packets one byte at a time in a buffer, then dispatches the complete packet to a handler. It’s quite messy.

6

If you want to see the bytes going between Vera and your Device, you can enable Verbose Logging. All the log lines starting with “[tt]52[/tt]” are received data, those with “[tt]51[/tt]” are sent data.

Here’s some RAW output from my Brultech over a [Wifi] Serial interface:

[tt]52 06/12/11 6:35:17.511 0x30 (0) <0x5012>
52 06/12/11 6:35:17.514 0x2e (.) <0x5012>
52 06/12/11 6:35:17.516 0x63 (c) <0x5012>
52 06/12/11 6:35:17.518 0x6f (o) <0x5012>
52 06/12/11 6:35:17.551 0x6d (m) <0x5012>
52 06/12/11 6:35:17.553 0xd (\r) <0x5012>
52 06/12/11 6:35:17.557 0xa (\n) <0x5012>
52 06/12/11 6:35:17.560 0xd (\r) <0x5012>
52 06/12/11 6:35:17.563 0xa (\n) <0x5012>
52 06/12/11 6:36:05.301 0x47 (G) <0x5012>
52 06/12/11 6:36:05.303 0x45 (E) <0x5012>
52 06/12/11 6:36:05.306 0x54 (T) <0x5012>
[/tt]

for Line-oriented output, where the PROTOCOL Block uses CR or CRLF, you’ll see something more like the following, with the CR and/or CRLF chars stripped:

[tt]52 06/12/11 8:26:28.148 0x3f 0x52 0x45 0x43 0x20 0x30 0x35 0x20 0x34 0x35 0x20 0x31 (?REC 05 45 1) <0x4811>
[/tt]

The LogLevels line in Vera’s config file:
[tt] /etc/cmh/cmh.log[/tt]
define exactly which log lines are emitted/filtered, but the default verbose logging should capture what you need.

NOTE: There are two PROTOCOL Tags, one in the I_xxxx files, and one in the D_xxxx files. I forget which does which so I usually set both in my plugins.

As @futzle indicates, there are a few examples of code that does this over on http://code.mios.com. You can browse the source online for things like the GE Panel, the Onkyo Receiver (which both do RAW) and also the Paradox (does CR), and the Panasonic TV (does STX-ETX) just for examples of the differing styles.

7

Thanks for all the hints. I will check this out next week (need to get some cables first).

I got a vera2 a week ago. I have a powermax+ alarm system. The powermax only has an x-10 output to send status on arm/disarm/alarm/… It also has 2 inputs for wired sensors. So I built a little board that translates the x-10 into rs232; and rs232 can activate the 2 wired inputs. It works using a terminal program (minicom). So when I now arm the powermax it sends on the serial something like A 1 ON. I started to look at that luup language last night and got stuck at this stupid problem. I was able to send a command to switch a wired input from the vera to the powermax. But works only once, then I have to reboot the pic. I will get there…

8

The culprit was the wrong protocol statement in the I_XXX file. I had a contradicting statement in the I_ and the D_ file.

Thanks guessed.

9

From the source code I can tell that they both set the same variable, which means that the protocol will be the one from the file that is parsed the last, which I don’t know what that is. This is also true for the commProv tag. I usually put them in the device file because it seems more logical to me this way.