Anyone interested in developing an ISY-99(4)i INSTEON Binding?

[PeterD]

Hi -

I've been watching some of the issues others have been having with bindings to the INSTEON Hub or to the PLM directly. With 100+ INSTEON devices automating nearly everything in my home from lights to ventilation to water management, I've found the Universal Devices ISY controller indispensable. (Much of what Smarthome's INSTEON Hub does is clearly built around lessons learned from the ISY.)

I settled on INSTEON as my primary technology when I was ready to transition away from X-10, since it represents an excellent balance of cost and reliability for large-scale control of household wiring (when I'm done with this work-in-progress, there will be only 1 or 2 non-INSTEON switches in the entire house). However, as with any closed system, there comes a point where other technologies need to be integrated (in my case, DMX) which drives you to search out other options. The ISY does have some ability to drive external devices via TCP/UDP (so, for example, I've experimented with adding a bit of Milight control to my setup), and has begun incorporating Z-Wave (and limited Zigbee) support directly on some models. But once I found OpenHAB it became clear that the right model is to let OpenHAB be the primary (technology-agnostic) controller, and delegate communication with and management of INSTEON devices to the ISY.

The ISY excels at managing the network of INSTEON devices - greatly simplifying the process of adding devices and linking them together into "scenes." A key notion here is that you can abstract every device into at least one scene - even if it contains no other device. When a device fails (any electronic device directly coupled to the powerline is going to be susceptible to noise & spikes and it's a given that once you have a lot of them, some will eventually die), the ISY allows you to replace it without having to hunt down and change every reference to its unique INSTEON address. And the folks at UDI do a great job of keeping abreast of each new INSTEON device (or new firmware version of existing devices) which is released.

(For those not familiar with INSTEON: most of the day-to-day interaction the user has with actual switches, dimmers and keypads to control loads such as lights, fans, etc. involves only the network of devices themselves. Even when the press of a single button controls fairly complex groupings of multiple devices (including some things turning on or off at the same time others brighten or dim to preset levels), or when a sensor triggers a pre-set action (such as a cooling fan coming on when a thermostat reaches a given temperature), the automation controller is not directly involved (although it is kept informed of the state changes).

So, I envision an OpenHAB binding which:

• queries the ISY's REST API (& possibly the SOAP API as well) to learn the names (& "node-ids") and capabilities (e.g. can this be dimmed?) of scenes,
• updates the OpenHAB configuration accordingly so that these scenes show up as controllable items within the OpenHAB UIs (I realize this may require that dynamic configuration capabilities (such as HABmin uses) evolve further) and
• subscribes to ISY state-change notifications so that the OpenHAB UIs stay in sync with changes made via physical controls, and OpenHAB rules can be triggered by INSTEON switches, dimmer paddles, keypad buttons and sensors.
  

At the moment, I'm far too busy on the construction portion of the home renovation which catalyzed the INSTEON installation to undertake development of a binding. If nobody else steps up, I would do so myself - but likely no sooner than this time next year. So I'm putting out the call to see if someone else is interested in developing this. If so, I would certainly work with whomever to give the binding a good shakeout.

Cheers,

Peter

[hae...@gmail.com]

I got the same problem Peter has! I am looking for a control system sitting on top of the ISY. The ISY is fantastic in handling Insteon devices. Since this was posted, were there any further developments not reflected on the list?

Thanks,

Marcus

[Kirk McCann]

Why go through a middle man when you could have openhab control it directly? I have an Isy device and no longer use it. I haven't found anything that openhab can't do natively that the Isy device can do.

Just my opinion.

[notana...@gmail.com]

Are you using an Insteon PLM with OpenHAB? Mind sharing your bindings? I'm seriously considering the ISY again. I lost one to a house fire and have been trying to get all my stuff back up and running. No luck with OpenHAB and my PLM as I'm not a programmer. I've been through the interface, tried habmin, edited config files. All of which as been a headache. I can manipulate with plmsend but that's no easy task. I need to create a family friendly setup and the ISY994 is looking more like the bridge to do that with while offering the ability to be controlled by other sources.

[Chris Graham]

There has been an Insteon PLM binding part of the master git repository (https://github.com/openhab/openhab/wiki/Insteon-PLM-Binding) developed by Bernd Pfrommer and can be used in the nightlies generated once a day when commits a merged (https://openhab.ci.cloudbees.com/job/openHAB/) for a while now. I use the Insteon USB PLM with it, the Serial PLM also works.

[Kirk D Mccann]

I'm using the insteon PLM binding.

--
You received this message because you are subscribed to a topic in the Google Groups "openhab" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openhab/v3XRMe8Fy_k/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openhab+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
Visit this group at http://groups.google.com/group/openhab.
For more options, visit https://groups.google.com/d/optout.

[Tom Gerhard]

I'm also a fully committed ISY user.     Right now, I'm looking at Openhab as a bridge between my ISY implementation and non-Insteon devices.   I've already built a version of what PeterD describes using node.js, so I know the ISY event subscription model would work (I'm using the node app to provide a cleaner (IMO) REST interface than the ISY (users device names instead of addresses, updates variables based on date, provides a (very crude) device status web page), and was hoping to move to Openhab instead of going further with that app (I was heading toward building a configurable web interface, but Openhab's UI would eliminate that work).   My ISY is already integrated with a patchwork of external systems (thermostats, alarm system, weather station, temperature sensors on Raspberry Pis) vi shell scripts and small node apps.

I'm not ready to switch away from the ISY -- I have a pretty decent WAF right now, and don't want to risk regressions in the several dozen ISY programs as I convert them to openhab rules.

For me, the ISY binding would be a bridge that would allow me to integrate openhab with my working system, possibly leading to a total replacement, but possibly not.   My first step would be to consolidate the non-Insteon stuff into openhab, and then decide whether to move the insteon over as well.

[Simon Burke]

 I also have an isy994 that is already integrated, and working well for me. It  handles the "low" level stuff such as insteon linking, updates and basic rules very well and except for power outages hasn't had any "down time" since I  installed it nearly 4 years ago. Specifically ISY handles all the insteon linking stuff very well and is worth it for that alone IMHO.

So  I want to use openHAB for the higher level rules and more "intelligent" stuff that can tolerate some downtime periodically (of order of a  couple days total per year maximum). And I want the "low level" stuff to be very reliable, less than a few hours down time per year. For me,  ISY meets that requirement , and my personal opinion, from experience,  is that anything that runs atop windows/linux/mac wont meet that reliability threshold. 

I have tried enabling a usb PLM for openHab via the insteon PLM binding in addition to the ISY, but i see three issues with that path as a complete  replacement for ISY

1..    The "Delay" in openHab "seeing"  ISY events and visa versa is just annoying (not an issue if i replace ISY, but a problem if i run both)

2..    having to handle linking and insteon ID's again in openHAB is just tedious (this is a  deal breaker for me if i replace ISY totally)

3..    Reliablility concerns around total down time per year average of an "OS" based system for low level functionality, which is not a concern for higher level functionality, this is also a deal breaker for me if i replace ISY totally

So i wish to continue to use insteon + ISY for low level functions for reliability and leverage openHAB for the higher level features and functionality. For my needs its a good trade off, you needs may vary and you may have a different perspective.

 

I am not all that familiar with java so writing a direct binding  is probably more work than i can support alone, however using mqtt as a bridge into openHAB and ISY has many attractions. So my thinking was 

1.. A  ISY <> MQTT bridge using ISY api (rest), external to openHAB

2.. enable openHAB's mqtt binding to connect ISY to openHAB via  an mqtt broker

My initital concerns with the above

1.. response time from openHAB -> isy -> insteon doing something

2.. reliability of the broker link (what happens if stuff gets "lost") ?

I wrote some quick perl code to test the idea (i wonder why do i feel the need to appologize these days for writing in perl, anyway very sorry), and I have some conclusions

1.. perl is happy to subscribe to ISY and see events with very reasonable timelyness

        status: alpha  code written and tested

2.. these ISY events can be posted to an mqtt broker and seen externally (i use mqtt-spy to verify)

        status : alpha code written and tested against mosquitto broker and apollo active mq broker on same and seperate server to openHab

3.. enabled mqtt binding in openhab and manually tested (mqtt-spy) can both set and see switch changes inside openhab

        status: mqtt binding to external world works

whats left to make this work is following

1..  read room+device info from ISY and create openhab setup files to map names between openHAB and ISY

        status: alpha code written but not well tested yet, produces 4 files, 2 item files for mapping, a simple map file and a section of config for insertion into the openhab.cfg, MQTT Broker section.

./isy.pl -verbose 0 -config /tmp  -mqtthost mosquitto

running isy

RunEventQueues(0,-1)

isy_event_monitor() on 192.168.24.221

CONNECT from 192.168.24.216:34854

RunEventQueues() looping for count of -1

created openhab setup files, please copy/incorporate them into your openhab setup

        /tmp/items/ISY99_Rooms.items

        /tmp/items/ISY99_Devices.items

        /tmp/transform/ISY99.map

        /tmp/ISY99.cfg

isy done

2..  get isy.pl to write and read to the mqtt channel openHAB is looking at in correct format (reproduce manual step tested using mqtt-spy)

           status: alpha code written but not well tested, can receive events from isy,  format message and then get ready to send to the mqtt broke, mqtt send/receive code is work in progress, below shows simple light on off event from ISY ready to send to openHAB. Receive still code work in progress 

 ./isy.pl  -verbose 1

running isy

RunEventQueues(1,-1)

NI(1) (4395) HTPC2::ISY/RunMonitor()

isy_event_monitor() on 192.168.24.221

CONNECT from 192.168.24.216:34856

RunEventQueues() looping for count of -1

ProcessEvent()

Add code to send [/openHAB/in/Home_Office_eLight/command] => [OFF]

ProcessEvent()

Add code to send [/openHAB/in/Home_Office_eLight/command] => [ON]

My original concerns regarding response time and reliability of the broker are still "open", and i guess i'd need to have something running for a while to assess the answers

At this point i think i have a solution that works for me, but if anyone wants to "help" or contribute/share, i'd be happy to engage .

cheers

Simon 

[Tom Gerhard]

Simon, we've arrived at the same design.   I've implemented in node.js instead of perl, and am posting to mqtt using the ISY device names, with spaces removed:

$ mosquitto_sub -v -t /isy/#
/isy/Pond-winterpump 0
/isy/Bedroom-Dresser 181
/isy/LivingRoom-Hallway 170

This will allow me to config Openhab without any intermediate files.   I've yet to build the translation to take the ISY 0 -255 and turn it into 0-100 mapping for Openhab (I just wired mqtt into my node program last night), but I expect that to be straightforward.  I'll create a REST interface using the same device name mapping so that I can use http to control  (my program currently supports a rest inteface to run a program by name or update variable by name, so this will be a logical extension).

[dvand]

Want to share your node.js implementation at all? I'm interested as well.

[Garrett Power]

I am also looking for ISY integration. I have both a MicasaVerde Vera controller for zwave and ISY for insteon. I wrote a plugin for the Vera controller to subscribe and communicate with the ISY controller. It has been working well. I was going to create a binding for OpenHAB, but I have yet to still figure out how the bindings work and I very time limited. For the time being I am going to use the MIOS binding to retrieve my ISY devices using my plugin. I hope we can all put our efforts together and get solution. The ISY controller is a solid Insteon controller.

[Kirk D Mccann]

In using the insteon USB PLM

--

[Tom Gerhard]

Don't mind at all - had that in mind when I started to prototype it.   Will try to get it organized later this week.

[Simon Burke]

yup mqtt seems a  good way to go, i got rst of code completed and performance seems quite acceptable, less than 6mS from click to update across openHab, ISY and rest web interface

the exported .item filed work fine and aligns openHAB names with ISY names and my existing rest interface names. 

To make direct mqtt communication works (i had to remove chars ".()"  and replace " " with "_" to make valid openHAB names

First New problem i have to align initial item state between ISY and openHAB, but looks like i can just use the openHAB rest API to do that when they both boot up, not a big deal

Second problem is openHAB seems to want very "low level" mqtt mesages, and  some of my other data sources are in mqtt now, but  more structured data. I cna write somethign to bridge one to the other or try to parse inside openHAB, but i came across nodered  (nodered.org) that seesm ot make that problem easy to solve, so I'll install and play with that first. If the nodered thing works out, then I'd be very interested in grabbing your node.js implementation

Hope you having as much success, seems like this is a quite workable solution and i like the idea of having mqtt as the backbone for integration. OpenHab can then focus on the GUI presentation and rules, not external "parsing" and data translation.

cheers

S

[Garrett Power]

I would also be interested in the node.js implementation. I may write my own to play with it. It sounds like mqtt would be a good starting point. I have done some reading and I like the idea of mqtt and the fact that you can create the binding in any language you want and push it to the mqtt broker. It sounds like node.js is the way to go. I still have much more research and reading to do. If you need any help with the code please let me know.

[Tom Gerhard]

I'm removing some cruft from my app and writing up some documentation; hope to have it on github in the next few days.   It has plenty of rough edges, but should give you a good start.

[Tom Gerhard]

Takes deep breath...

https://github.com/tcgerhard/isymonitor  has my app; it's pretty raw, as once it met my basic needs (trigger programs and update variables from a Raspberry Pi),  I lost some momentum.   If you find it useful, I'll reorganize my todo list and dig back in.

[Garrett Power]

Thanks for the code. I'll have a look at it soon. I have a proof of concept that I am working on that uses node.js (thanks for the mention) which connects to the ISY and listens for events via the soap api. It will then pass the events to OpenHAB via MQTT. I am working on the code that will listen to control request via MQTT and pass them to the ISY. So far the proof of concept is working well. Obviously there are bugs that I need to work out. Still need to figure out how I want to structure the MQTT events and control messages. Once I have it in decent shape, I'll post the code for others to use, tweak, etc.

- Garrett

[Daniel Daugherty]

Hi,  

Anyone still working on this?  Right now just need ISY to OpenHAB communication so will be looking at Tom G's code.  Want to do some basic control of my Pioneer Stereo via ISY.  When basement lights off turn music off in the basement.   

Daniel D.

[Gregory Keyes]

Second that curiosity. Anyone got this working with an ISY? 

[Simon Burke]

I have not played with Tom's code much yet, so can't confirm it works for me, but have no reason to doubt it works either

i have a working system implemented via a pair of perl scripts to talk to isy and openhab, and a nodered instance for higher level logic

   isy.pl <-> MQTT message broker (mosquitto)

   openhab.pl <-> MQTT message broker (mosquitto)

   nodered <-> MQTT message broker (mosquitto)

   its been running fairly reliably for me since february timeframe, passing events and 

variable status/updates via MQTT. I have now disconnected openhab from my Insteon

network (USB hub) and it works via MQTT only to my isy device.

  so conceptually i think the MQTT approach is quite valid and workable, what language 

is used to talk to MQTT is a just personal choice.

  I plan to find some time to download and try Tom's code for the ISY piece, but its not 

urgent for me right now.

S