implies that the “[tt]crlf[/tt]” value expects both a CR and an LF, but if I use that my [tt][/tt] block of Lua never gets called. I suspect it’s waiting for an LF before it delivers a line of input to me.
I tried [tt]cr[/tt] and got the same result.
Questions:
a) Does the CRLF expect literally both a CR and an LF in all cases?
b) Is there separate support for CR?
c) Is there a way to have the Vera itself “print” the data it’s receiving on a particular [Serial] device (I’d like to see what it’s seeing) … I’ve already validated input with [tt]telnet localhost 3481[/tt]
d) Can you log a warning/validation when someone uses a non-supported [tt][/tt] value?
For reference, a line from my Paradox Alarm interface might look like:
protocol “crlf” (the default if none is specified) appends a cr+lf to each outgoing line, and when it receives either CR or LF, it treats that as an incoming packet of data that is forwarded to the incoming handler. It ignores successive cr/lf’s, so, OK+cr+lf+cr+lf+lf+cr, which result in 1 call to the incoming handler with “OK”.
So:
a) Does the CRLF expect literally both a CR and an LF in all cases?
no, any combination is ok
b) Is there separate support for CR?
for incoming, this is there already since any combination is ok. I can easily create a ‘cr’ protocol that sends only a cr without a lf on the outgoing data
c) Is there a way to have the Vera itself “print” the data it’s receiving on a particular [Serial] device (I’d like to see what it’s seeing) … I’ve already validated input with telnet localhost 3481
It does this already. Log level 50 is on by default and is the output from lu_log. Log levels 51 and 52 are for all incoming/outgoing data. They are off by default. Edit /etc/cmh/cmh.conf to add them to the LogLevels line, or just turn on Verbose logging (turns on all LogLevels), then: tail -f LuaUPnP.log | grep ‘^01|^5’ to see all Lua related message (50,51,52) and critical errors (01).
d) Can you log a warning/validation when someone uses a non-supported value?
Done. Now you’ll see a warning (log level 02) “IOPort::SetProtocolCallBacks unknown protocol %s, using crlf”
I’ll do it right away. If you have problems like you’re describing, don’t worry about banging your head too much. It could just be a bug or something we didn’t document well. We can chat over Skype or something and I can login remotely and see what’s going on and fix it.
Thanks Aaron. I have “the basics” working for read (via [tt][/tt]) with the [tt]CRLF[/tt] Driver, but writing back to my alarm definitely isn’t working, and it’s not enjoying some of the random data it’s being sent ooband to my [single] startup request. From time to time, it’s returning lines and lines of it’s erorr code that look like “[tt]…&fail[/tt]”. These appear to occur in bursts as a response to whatever’s being sent to it (I only send to it at startup). Unfortunately I can’t tell why it’s being sent anything at those times (it’s like the RS-232 line noise of old, except I’m using USB Cable)
In my setup, I can either get no <[tt]incoming>[/tt] events, using the “default” serproxy binding, or I can get them delivered if I enter an IP Address of localhost (127.0.0.1). Of course, once I use that work-around, I get other errors like:
… but it works, and it lets me make progress. I’ll try it again tonight, and file a ticket if this continues. It definitely shouldn’t be getting ooband data being sent to it like that.
Guessed, I just posted a new firmware 789 which includes 2 additional protocols: cr (which terminates all data with a carriage return only) and lf (which terminates all data with a line feed only). Tomorrow I’ll add also a ‘raw’ protocol which will do no termination and will call your incoming function for every character received. Because of the overhead to setup a Lua function call for every single byte that comes on the serial port, I won’t recommend the ‘raw’ protocol except while testing and waiting for us to implement whatever is the real desired protocol.
I’m having the same upgrade problems others appear to be having with that release. Once we get those all sorted (PM sent) I’ll give the new option a try.
For my ETA furnace plugin, I need a protocol that handles messages between { and } (no cr or lf).
For incoming data, it needs to strip these characters and pass on what’s in between, for outgoing, it needs to add them.
Could you build something like this for me?
Best Home Automation shopping experience. Shop at Ezlo!