nickandrew / ls30 Goto Github PK

Could be a local config issue but straight out of the download I found the code had problems finding the library files.
eg errors like

Can't locate AlarmDaemon/Controller.pm in @INC (@INC contains: .....

Easiest way for me to work around it, was to add the local lib path via the following line at the top of each file.

#add a local path to lib
use lib './lib'; 

I'd started to write modules to do asynchronous I/O built around a select() loop for several years and included my work to date into LS30. Since then I found AnyEvent which does a much better job of it, so rewrite the event loop parts of LS30 using AnyEvent.

I know that I can call arm.pl and see whats going on but ideally what I want to do is have some code execute any time the alarm state changes (away/disarm etc)

The events just doesn't have enough information.

I'm guessing if it could be done it would have been :)

For the daemon to send responses to all clients risks confusing those clients request/response pairs.

To implement this, the daemon needs to use LS30::Commander.

Also, there could be an option for a client to be a passive listener, to receive all other clients requests and responses in its feed. Such a client could track the state of the device passively, as was my intention about 4 years ago.

I could totally rewrite this in Mojolicious nowadays and provide a REST/Websockets interface.

Or somebody else could (hint hint).

OK to listen on an ipv6 socket if the listening address is fully described, i.e. ":::1681"

Can't make an outbound ipv6 connection using IO::Socket::INET6 version 2.54 unless my local hack is included. Should I add that to the git repo?

Could be a similar problem to my issue #3, this one is with watch.pl reporting an error

Unable to require class Watch at bin/watch.pl line 31

Which I was unable to get around with the lib include. Could be my complete absence of perl knowledge not helping either.

The LS-30 protocol does not ensure that a response matches up with a request. I tried a query-all across a link with long (and varying) latency and I found that the client can give up on a response for an earlier query (A), and send later queries (B,C,D). When it receives the first response (for A) it may be waiting for a response for B, and so get out of step.

Part of the problem is on the client end - the client treats the request/response pair as a unit of work and it has to have some kind of timeout on reading the response. I could make the timeout bigger - but, how big? 60 seconds? 120 seconds?

I could also make the processing of responses asynchronous with the sending of requests. In other words, the client could send all of (A,B,C,D) without waiting for any response, and later when the responses come in, they are processed in that order. Also if we miss a response, say we send (A,B,C,D) and we receive (A,C,D) then the response 'C' is not matched to the request 'B' and so B would be marked as "no response" and the response would be correctly matched to 'C'.