Zwave - DO NOT MERGE (see comments)

[pkubat]

Alex, I am also working on similar code. But to support A/V devices that have "network" control, Roku and Denon. Also, looking to add LG TV's serial. I saw your branch and feel its very related. I opened this so I could comment directly on the code.

A few other comments:

1. Is the project name correct? Seems it has grown beyond lirc.
2. Devices and remote are very related. If fact I think that "remotes" should be dropped and devices used, as one controls "devices", thoughts?

I hope you don't mind the feedback.

BTW, great work.

[alexbain]

Some answers to your initial questions:

1. Yeah, lirc_web isn't going to make any sense if we add gpio, rf, zwave, and http based devices. I'm tempted to fork the project and call it osur or keep all of the new protocols in a v2 branch until I've sorted out the long term way to handle this

2. Agreed. There should likely be a generic device type that has N adaptors for each type of protocol. @OvisMaximus and I exchanged some emails about this.

I settled on the "do the work required to support a few protocols, then figure out a proper architecture" approach since I'm not entirely sure all the requirements yet.

I definitely appreciate the feedback - and I'm curious to see if the HTTP devices you have would work using the work I've done so far.

[alexbain]

One other thought that would be good to figure out is how to add/remove support for protocols based on what your own requirements are. When the project is called lirc_web it's safe to assume everyone will want to have lirc installed. If we're adding in N new protocols and you don't have any Zwave devices installing zwave dependencies isn't strictly required.

[pkubat]

All good ideas @alexbain and @OvisMaximus. Sorry for the delay in the response. This week was busy...

A few questions/comments:

1. Is there a one-one relationship remote to device? I would think there is.
2. Also, @OvisMaximus I am going to use TCP (not HTTP) for the Denon. Its seems pretty responsive.
   echo -e "PWSTANDBY\r" | nc -v <ip of receiver> 23 Here is a library with that support: https://github.com/phillipsnick/denon-avr
3. Doing some research I think each device class will have its own transport and not a generic tcp or http. Also there are some rs-232 devices too (I am using that for LG TVs) and other physical connectivity.
4. @alexbain did you start a new fork or branch?

[alexbain]

@pkubat

1. Yeah, I believe a remote should be just a type of device and they map 1:1
2. I agree that different classes or types of devices will have an increasingly varied array of protocol options. I'd like to come up with a list of devices we all have so we can try to find the shared functionality / interface a device would need to have.

[alexbain]

4 - Yes - I setup an osur branch we can start working from, for now. I think keeping it attached to the lirc_web project for now will be fine. Once we've made some good progress I'll fork the project.

[OvisMaximus]

Yay. I'm currently refactoring the macro engine stuff so that it can play macros depending on virtual states which are set and reset by macros themselves. I'd like to contribute it to osur as soon as the basic functionality is up and running.

Still feels like rookie code. Colleagues of mine suggested to have a look at some libraries for the macro engine stuff:

• bluebird (for promises) http://bluebirdjs.com/docs/getting-started.html
• orchestrator (for resolving state dependencies and triggering macros) https://github.com/orchestrator/orchestrator
• and https://www.npmjs.com/package/madlib-promise-queue, for keeping the timing of hardware channels when playing macros simultaneously.

Currently this is distracting me too much, I'll get the macro stuff up and running without thinking about parallel execution, but sooner or later I'll face this one. And only if I'm triggering a macro while another one is still in progress.

[pkubat]

@OvisMaximus not to add to the distraction, maybe macros are finite state machines? The states could be physical or virtual based if the device / transport support getting state, Or better to add the fsm to the device and keep the macro dsl very simple?

[OvisMaximus]

@pkubat yeah, sure. the combination of macros, states, transitions and dependencies form finite state machines. The macro engine is the toolkit to describe these state machines. Every configuration may describ a different machine. This is the point, where orchestrator may be helpful for implementation.

For my scenario no hardware sensors can represent a state, although this would be possible and also the better, more stable and resilient solution. But there are also state changes, which involve more devices. It's not simple per se, we'll have to do a good job on making it simple for the customer.