For what it’s worth, I’ve started working on this. I’ve got a preliminary python asyncio library going and stubs for a Local Push hass component. Code’s on https://github.com/nugget if anyone wants to assist.
I doubt I’ll have it in good enough shape for 0.38, but maybe within a month or so.
I do have a 2012 model hub with built-in PLM that uses Ethernet port with a port of 9761. I’ll probably need to figure out how to add code that connects over the network.
We have local support via the hub in the latest release of hass. Please check it out. It is very basic right now and the three of us who wrote it are not experienced python developers {2 of us do php). So we are always looking for more developers to help. I wrote the underlying library and hope to add new devices in the future. Where it needs work right now is dealing with keeping up to date on manual switch changes or changes outside hass
Can this work without username and password? Because when trying to connect to Insteon 2012 Hub, I get a Hub Not Found in my Android smartphone even in the same WiFi network.
(Bolded the text in case some missed it.)
In the component config you’ll need to provide the exact ip, user, and pass. Also the port if you are using a non-standard one. You’ll need to have the hub set to a static ip as well
Okay, but you missed the part that I got a “Hub Not Found” error. I already have a static IP and OpenHAB is controlling it. I already have device IDs setup and I am using this component in the meantime:
As for Insteon app for Android, I followed instructions but so far, no luck.
Scroll down to: Setting Up Insteon Hub (2012)
My 2012 Hub is in my same Wi-Fi network. I followed instructions as it is but no matter whether openHAB is running or not, the Insteon app told me “Hub Not Found.”
So I have to stick with custom component with openHAB running in the meantime.
Just to clarify, Insteon PLM support has nothing to do with the Hub or the existing Insteon(Local) support in hass. My work is to add support for the Insteon PowerLinc modem interface (model 2413U) which is a dual-band USB interface to the INSTEON network. It should also work with the older RS232 serial device as well, but I don’t have one of those on hand to test.
I’ve got a working component now with full support for dimmer and lamp modules. Now I’m working on extending it to include sensors as well.
Yes it does. Insteon PLM support is built-in to Insteon Hub model 2242. The port that connects to the PLM from a server is 9761. The fact that Insteon PLM support has nothing to do with the hub is true only with the 2245 model because the 2245 does not support X10.
But then, I went ahead to purchase an Insteon Hub 2245 which the Insteon app cannot find my 2242 hub and I’ve used the Insteon local component. The fact that Insteon app can’t find my 2242 hub even in the same Wi-Fi network led me to believe that the Insteon app does not support the older model, so now I have two hubs: 2242 and 2245.
That’s going to be extremely confusing for all the people who use the term “PLM” to refer to the “PowerLinc Modem” product, then. My component is currently named ‘insteon_plm’ (aligns well with the ‘insteon_local’ component name).
I didn’t realize that the Hub was providing a faux PLM interface over IP.
The hero we need! I like the looks of this so far. It’s way better than anything I’ve come up with experimenting on my own (I got as far as decoding messages from the PLM).
@nugget I’m not sure if it’s my hass newbie-ness showing, or if I’m blind, but aside from installing the package, was there a how-to-use-with-hass document in the github repo that I didn’t see?
I’m writing it with the intent of submitting it into the core hass package (won’t be done in time for 0.38, but 0.39 towards the end of the month is realistic). That means it’s not really structured for easy drop-in onto a normal hass installation as a custom component.
You might be able to drop the insteon_plm.py and light/insteon_plm.py files into your custom_components directory, but I haven’t tested that.
If you want to run it now (or even just experiment with it) you’d need to git clone my fork of hass and run it (the insteonplm branch). Not something you’d want to do on your production hass install, but it’s perfectly viable to run in a VM or something if you want to play around with the work in progress.
If anyone is interested in testing, this process should get you up and running:
https://github.com/nugget/python-insteonplm/blob/master/HASS.md
If you do get it set up I’d love to know how it goes.
For the Hub Not Found… try going to it in your browser:
http://(IP):25105/
It should prompt for the user/pass your hub is configured for, and then you should get an info page
Just to clarify for anyone reading the thread
Insteon Local support is basically for the HTTP API which is on port 25105
The Insteon Hub component is for the cloud-based REST API which talks to the hub via a back connection between the hub and Insteon
The PLM is a TCP-based protocol (port 9761 I think) that is not supported on the latest Hub model
So the PLM protocol is different than the HTTP API…older Hubs supported both
Further clarification, the TCP-based PLM emulation offered on the older hubs was mimicking the PLM serial/USB protocol which is how the PowerLinc Modem devices (2413U and 2412S) communicate. These devices are old and crusty, but they’re still produced and available for sale and offer a great way to provide truly local, non-cloud INSTEON integration. I submitted my insteon_plm component pull request earlier today and it’s on track for inclusion in 0.39. And, again, has nothing at all to do with any model of INSTEON Hub.
With your component we should have pretty good coverage device-wise. Would be nice if we could coordinate/share code somehow as we add more device types. The low-level calls to the libraries would be different but we could share similar code in how the HASS components are structured. It might even be good one day to have a combined component that could work on all devices and just call different libraries depending on what device was used.
The one last thing that might be nice would be support for the USB dongle (Insteon 2448A7)…those seem fairly cheap and would be easy to plugin to a raspberry pi, etc. but I’ve never actually heard from anyone who has one.
Interesting, I didn’t even realize that dongle existed. From googling iooks like it is a regular PLM device just like the 2413U (except lacking power line signaling, obviously) so I suspect it would work with my insteonplm python module without any modifications.
I’ve looked at your work on insteonlocal and found it very helpful, but I’m afraid that unless you’re planning to migrate to an asycio approach for the library there’s not going to be a lot of opportunity for code sharing, especially at the hass component level. The PLM protocol being serial lends itself very well to event-driven asyncio operation. It’s all callbacks and event loops. No polling and no regular function calls.
Additionally, since the PLM devices are far more basic, there’s a lot of extraneous scaffolding I’m having to construct to make up for the significant lack of metadata about devices and their semantics. It’s a lot of ugly and cumbersome effort that your Hub API lets you avoid. So in a lot of ways we’re not really trying to solve the same problems even if the underlying hardware is the same.
Yes unfortunately the only way to know what is going on with the hub is to query it’s buffer at regular intervals, which makes it very hard to do any type of event-driven approach
I just saw this in the 0.39 release and I’m super excited. Outside of dimmer switches and modules, what are you planning to support?