Just getting started with openHAB in conjunction with a 2014 insteon hub. I’m testing out with one switch to get familiar with rules and configuration.
I have it configured so that I can toggle the switch off and on from openHAB web console, which also results in my rules triggering.
However if I toggle the switch from the insteon app, openHAB web does not see the status change when I refresh, nor do my rules trigger.
I can however see in the debug logs that openHAB is receiving the on/off messages about the switch from the hub.
Oh so this is expected behaviour? If so, this makes it quite unusable for any type of automation based on insteon messages. For example how could rules be triggered effectively from insteon motion sensors.
I do see a log entry when I flip the switch, almost immediately, indicating that openHAB has received the state change, but for some reason this does not trigger rules or update UI.
The device will send out a message to devices it controls, such as hubs or plm’s. With sensors, I think most of them can only be configured where the device sends requests to devices it controls. If you use the latest 1.8 binding, the log files will tell you how the devices are configured. Is there a reason you are mixing openHAB with the insteon app? There is both an Android and iOS openHAB apps that you can use.
I think I’m confused then. Let’s take the insteon application out of the discussion, because the same behaviour exists if I physically toggle the switch.
So based on what you are suggesting, I could not reasonably do something as follows:
if a switch is toggled on, make an API rest call to an external service
In other words, trigger actions outside of the Insteon envelope based on Insteon device status changes.
I am using openHAB 1.8 with the 1.8 binding, and I do see debug messages immediately when the switch is triggered manually on and off, however this is not causing my rules to fire. The rules only fire when I toggle the switch using the openHAB application. Is this expected?
It’s almost sound like you’ve only got the hub set up to control the device, not to respond. If it’s set up both ways, you’ll see something like:
2016-01-02 09:09:16 INFO o.o.b.i.InsteonPLMActiveBinding[:611]- device 23.9F.AD found in the modem database and the modem controls groups [0xFE] and responds to groups [0x01].
Looks like the hub is configured as to both control and respond to the Attic lights. Can you turn on the light switch manually and include the log entries?
I did some testing with physically flipping the switch, and it seems to work properly. However, it seems that after a few cycles of turning the switch on and off, it sometimes stops working until I restart the openHab server.
Using the Insteon app, it never works (updating the device status in openHab.
One thing to note, I’m running in a Docker container. Is there any special networking requirements that may cause problems when running in a container?
The openhab binding just uses the PLM modem inside the hub. The same PLM modem is also used by the hub itself, so when you use your insteon app, the hub sends a message out that the PLM binding knows nothing about. It does see the ack come back from the device, but it discards it because it did not send the command in the first place (it turns out that in many cases you have to know what was sent out to interpret the ack). So the switch status is not updated until the next poll.
I added this as a known limitation on the wiki page.
You should get updates though when you flip the switch manually, because in this case the switch sends out a broadcast that will be picked up by the PLM modem inside the hub.
I don’t use docker, but it’s hard to imagine networking limitations that should only affect the insteonplm binding. Can you track this down more precisely: flip switch until it stops working, then look at the binding log to see if anything comes across, then look at the tcp stream with tcpdump to check if there is any traffic there? Is openhab completely shot or just the insteonplm component?
So if I understand what you’re saying, when the HUB api is invoked, the hub sends Insteon commands directly to insteon devices without going through it’s built-in PLM? This seems like a design flaw in the HUB, but obviously nothing that openHAB can fix.
I wonder if it would be possible to create an openHAB binding for the HUB itself?
As for the switch issues, it seems to happen if I trigger the switch open and close repeatedly in quick succession. I think I remember seeing a similar issue that someone had with a door contact sensor.
I’ll do some more testing and see if I can narrow it down (and provide some useful logs).
When the hub is sending stuff, it also goes through its built-in PLM, but as far as I know there is no way to find out what the hub is sending through the PLM. What can be queried is what comes back from the Insteon network. So the return traffic is visible, but not the outgoing traffic.
Yes, it is not too hard to cause message loss on the insteon network. It’s very doable even just on a 3-way switch setup, without openhab or insteon hub app involved.
