…so the easiest thing is simply to describe a new protocol option [tt]raw_1024[/tt] ?
Edit: ah… I think that is what you were suggesting earlier.
Two reasons I would not do it this way:
-
It requires a change in the device file to use the different protocol, and thus you need different device files for Vera vs openLuup? Isn’t that a first?
-
Vera owns that “namespace”, and if it were me, I’d want to avoid potential conflicts in the (admittedly unlikely) event they someday create a “raw_1024” with different semantics. More principle than likely conflict, I’ll admit.
Edit for clarity: I am recommending VERA add a new protocol. Until that’s done, and you can know what it is and its particular implementation semantics (if they ever do it), I am recommending to you just a flag in openLuup to change the behavior of “raw” so that it can do either: the Vera way of returning 1 byte, or the openLuup way of returning a larger block. Then when Vera does whatever it may do, yours still works, and you can implement theirs when you get around to it.
Hi,
@Patrick, yes my logic is just like yours.
It was my experience that it is slow indeed. On a Vera Lite it takes about 20 seconds to get 75K of data. It is one I do not need often, but still. With native sockets it is 3-4 seconds. Most replies from the Harmony are well below 1KB and take a 1 sec max. I guess I can get it to work, but I then have to make some sending queue as well so a reply is handled before a next message gets send. The Harmony also sends status messages when it feels to (without doing a write first) I need to process.
The connection is now kept alive by sending a WS ping, so as long that works it is ok. However, when it stops and I try again to connect internal errors from LuaInterface.cpp start flying around. Same happens when trying a new WS handshake by intercept, write,read. Both are a sure way to trigger luup reloads.
For now I’m going to stick to working with sockets directly. This is too shaky for my taste.
For improved handling I would first ask for a functioning is_connected and a close and (re)connect possibility without taking luup down (thats an ask from Vera, not you AK). Also to be able to read specified number of bytes on the raw protocol would help, i.e. an extra parameter. Many needing raw will likely have a similar message format as websockets so you know what to look for.
Cheers Rene
BTW,
Just tested handling that large request with intercept and using luup.io.read. Five minutes !!! to get that same 75KB. And yes, exact same logic as used in the incoming, just wrapped in a repeat and a luup.io.read to get each of those characters one by one. So that’s 10 time slower than incoming and utterly useless.
Cheers Rene
My bigger-scope prediction is that the bulk of IoT devices are going to be WiFi, and Z-Wave and its ilk will slowly be relegated to a very specific subset of devices. Time to market and cost will be drivers away from protocols like Z-Wave, not to mention the ubiquity of WiFi. So, for that to be at all sane, Vera needs to get its act together on sockets. LuaSocket under Luup doesn't cut it, and luup.io isn't showing well either. This all needs fresh eyes on it.
I agree 100% with the above. I did a high-end residential wireless control system in the late 1990’s (pre-Z-Wave, Zigbee, etc.) in the 900 MHz range with wallbox dimmers, switches and plug-in modules. A tiny cheap ~ 900 Mhz radio was all you could do in 1998—the idea of putting an 802.11b interface with software stack into a small device was simply not in the cards.
With HaLow (IEEE 802.11ah - Wikipedia) coming along and cheap, low-power 802.11g/n interfaces integrated into small MCUs, Z-Wave, Zigbee, and Bluetooth et al will fade away from the HA and IoT marketplace.
On a similar note to the discussion of the block, would it be possible to include a timeout tag of some sort in the device file. Perhaps 15 That way you wouldn’t have to modify io.open to accept additional parameters. This would apply to data only and not any specific calls to io.open for files and what not. And if you allowed the overall luup.io timeout to be set in an exposed variable, that would take care of general need based on one’s local network/machine response et al.
I don’t know enough about the UPnP spec to know if this would be disruptive to a plugin running on a vera-- in the sense of vera crashing because of an unrecognized UPnP variable.
[quote=“Buxton, post:26, topic:200471”]On a similar note to the discussion of the block, would it be possible to include a timeout tag of some sort in the device file. Perhaps 15 That way you wouldn’t have to modify io.open to accept additional parameters. This would apply to data only and not any specific calls to io.open for files and what not. And if you allowed the overall luup.io timeout to be set in an exposed variable, that would take care of general need based on one’s local network/machine response et al.
I don’t know enough about the UPnP spec to know if this would be disruptive to a plugin running on a vera-- in the sense of vera crashing because of an unrecognized UPnP variable.[/quote]
If you do your read/ in a , the 5,X return from the job lets you specify the timeout (the X return parameter). This seems to work as advertised on Vera, IIRC, although I’ve had no luck doing something responsive when the timeout occurs. There is a tag, which supposedly may contain Lua to execute when the timeout occurs, but I don’t think that worked as planned when I last tried, and I could have just brain-faded it. I need to go back and play with it; that issue wasn’t my focus at the time. The docs are just so vague and fragmented in this area. Ref: http://wiki.micasaverde.com/index.php/Luup_Declarations#.3Ctimeout.3E
Ok, but assuming is first handled/started in the vera with something similar to io.open (using the socket library), is there a way to set the timeout for opening the socket in the device file? This seems to be where the plugin I’m using stalls. Once the socket is open, data flows as predicted, so I don’t need to mess with the read timeout as that is handled by the plugin itself in the way you outlined.
Yeah, no idea there. AFAIK, Vera just keeps on trying to open the socket until it succeeds. Even luup.io.open() doesn’t have a timeout parameter, and it just returns and the socket is opened asynchronously (ouch). The docs basically say you need to write to it to see if the socket is open (fails if not). “…the actual opening of the socket occurs asynchronously and this function returns nothing. You will know that the socket opening failed if your subsequent call to write fails.” SMH :o
I’ve been modifying io.lua for properly handle data using delimiters other than “\r” or “\r\n” . I think is the easiest…