Do Insteon dimmers push status?

[Bob Igo]

Having had issues with some Z-Wave dimmers not pushing changes in dimming state to the Z-Wave network, I'm wondering if Insteon dimmers are any different. If you dim a light with an Insteon dimmer, does the dimmer push its changed state to openHAB, or do you need to poll the device (as I do with my Z-Wave dimmers) if you want its current state?

Thanks!

[Bernd Pfrommer]

Long answer:

Insteon dimmers do indeed send out a broadcast message if they are operated by actuating the button physically. The InsteonPLM binding picks them up (not sure about the InsteonHub) and will update the state in openhab.

There is a wrinkle though: if you have two dimmers in a 3-way setup (i.e. two dimmers controlling the same light), and dim the light from dimmer A, dimmer A will send out a message (which the InsteonPLM binding will pick up correctly). Dimmer B however will also pick up that message from dimmer A and change its state. So far so good, but: dimmer B will *not* send out a notification that it's state has changed, so openHAB will not learn about the change of dimmer B until the next time it's polled.

For this reason the binding has a configuration feature to declare two dimmers as "related": if the binding sees a message from dimmer A, then dimmer B will be polled right away, expecting that its state has changed.

Note that messages are not guaranteed to arrive, so occasionally I see the state of a dimmer change when the poll finally happens.

Short answer:

Most of the time.

[Nathan Stratton]

On Sun, May 10, 2015 at 12:19 PM, Bernd Pfrommer <bernd.p...@gmail.com> wrote:

Long answer:

Insteon dimmers do indeed send out a broadcast message if they are operated by actuating the button physically. The InsteonPLM binding picks them up (not sure about the InsteonHub) and will update the state in openhab.

There is a wrinkle though: if you have two dimmers in a 3-way setup (i.e. two dimmers controlling the same light), and dim the light from dimmer A, dimmer A will send out a message (which the InsteonPLM binding will pick up correctly). Dimmer B however will also pick up that message from dimmer A and change its state. So far so good, but: dimmer B will *not* send out a notification that it's state has changed, so openHAB will not learn about the change of dimmer B until the next time it's polled.

For this reason the binding has a configuration feature to declare two dimmers as "related": if the binding sees a message from dimmer A, then dimmer B will be polled right away, expecting that its state has changed.

Note that messages are not guaranteed to arrive, so occasionally I see the state of a dimmer change when the poll finally happens.

Can you provide an example on how to make two items "related"? I could not find anything on the wiki. 

-Nathan 

[Bernd Pfrommer]

Sorry, that fell through the cracks. I just updated the wiki page, it is documented now. And remember: the wiki refers to the very latest 1.7 version.

[Nathan Stratton]

On Mon, May 11, 2015 at 11:07 AM, Bernd Pfrommer <bernd.p...@gmail.com> wrote:

Sorry, that fell through the cracks. I just updated the wiki page, it is documented now. And remember: the wiki refers to the very latest 1.7 version.

Nice, thanks! Does it work with more then one relationship? I.E. What about 4-way setup?

-Nathan 

[Bernd Pfrommer]

You should be able to separate them with a '+':

related=aa.bb.cc+ee.ff.gg.

Not tested though.

Bernd

--
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/5VaXT-Jyqcc/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.
To view this discussion on the web visit https://groups.google.com/d/msgid/openhab/CAHubkyOorp943aUd-d2h-AicGZykCL-WeAnw31_XPsD%2BWXTkcQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Rob Nielsen]

I have multiple 4 way switches and the + works for me. 

[Nathan Stratton]

On Mon, May 11, 2015 at 11:07 AM, Bernd Pfrommer <bernd.p...@gmail.com> wrote:

Sorry, that fell through the cracks. I just updated the wiki page, it is documented now. And remember: the wiki refers to the very latest 1.7 version.

Can't tell you how much I love the new related feature, but I think I may have something mis configured. When I update my physical salve, I noticed that OpenHab now quickly updates the master to the same state! However, when I use the UI in OpenHab to update the slave or master I don't see the other switch being updated. 

-Nathan 

[Bernd Pfrommer]

You are right. I always manipulate both switches in sync when I do it from the GUI, since it doesn't involve physical effort. But I do so because fixing the problem requires mental effort :(

Here's the deal: when you manipulate the switches with the GUI, the switch does not send out the all-link broadcast message, and so the "related" device never changes its state. If you want the light to go off, you have to flip the switch in the GUI that has the actual load connected to it. And if you want the switches to stay in sync, you have to manipulate both of them with the GUI, in sync.

The behavior you observe is thus another consequence of Insteon's design decision to have devices send out notifications only when they are operated directly, but not when they respond to messages.

In openHAB, what we really want is a manipulator that combines the two switches into one: when you flip it, both switches should be sent a message to. Its state should reflect the state of the switch with the load connected.

One possible way would be to create a dummy switch, and have it trigger a rule that flips both corresponding switches whenever the dummy switch is flipped. Another rule would update the state of the dummy switch whenever the load bearing switch updates.

Bernd

[Rob Nielsen]

I only have load devices in my UI, I don't see a need to also have the related devices show up.

[Nathan Stratton]

Ya, that is a good point.

--
You received this message because you are subscribed to the Google Groups "openhab" group.
To unsubscribe from this group and stop receiving emails from it, 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.

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab/48cf8d32-f8ec-42ef-959f-20eef2b4c092%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

><>
nathan stratton | vp technology | broadsoft, inc | +1-240-404-6580 | www.broadsoft.com

[Bernd Pfrommer]

Rob, your solution is too easy and straight forward to be acceptable :)

And it actually does have a wrinkle: when you manipulate the device in openhab,  it only changes the state of the load. True enough, the light goes on, but the other switch of the 3-way configuration remains in the old position. So you end up walking into a room and one light switch says "on", the other "off". That does not pass the "wife" test!

[Nathan Stratton]

Anyone know how Mr House does it? My 3-way and 4- way Insteon just worked with it.

--

You received this message because you are subscribed to the Google Groups "openhab" group.
To unsubscribe from this group and stop receiving emails from it, 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.

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab/664a3828-8c73-484b-957e-d23249f947fc%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Bernd Pfrommer]

Somebody at MrHouse has done a really good job supporting Insteon, that's for sure.
But from all I can tell, this is not really an "Insteon" issue alone, but rather supporting the quirks of Insteon at a higher level, which apparently MrHouse does well, without the need of hacks.

Speaking of hacks: if we start with Rob's suggestion of just displaying the load bearing switch in the GUI, but still have an (undisplayed) item that refers to the non-load bearing switch, one could make a rule like this (warning: untested code):

rule "related switch on"
when
    Item loadBearingSwitch received command ON
then
    sendCommand(nonLoadBearingSwitch, ON)
end

rule "related switch off"
when
    Item loadBearingSwitch received command OFF
then
    sendCommand(nonLoadBearingSwitch, OFF)
end

That simply duplicates the commands to the relevant switch. I'll give that a try to see how it works in practice.

Bernd

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/5VaXT-Jyqcc/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.

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab/CAHubkyPAdzq89JTVheoJEHifZAUnCOrQrQ__-XZsauWOgRARwQ%40mail.gmail.com.

[Rob Nielsen]

Mine are dimmed, but doesn't paring the devices both ways take care of this problem?

[Bernd Pfrommer]

Try it out: I think that even if you link both ways, it is still the case that when the loaded dimmer changes state *because it receives an openhab command through the network*, it will not send out a broadcast to its responders, leaving them in a stale state. It obviously will send a message when you dim manually.

--

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/5VaXT-Jyqcc/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.

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab/ac8f95e3-62e4-49bf-ba6f-d7d276e98c40%40googlegroups.com.

[Nathan Stratton]

Correct, just tried it.

><>
nathan stratton | vp technology | broadsoft, inc | +1-240-404-6580 | www.broadsoft.com

--

You received this message because you are subscribed to the Google Groups "openhab" group.

To unsubscribe from this group and stop receiving emails from it, 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.

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab/555A0B9C.3010505%40gmail.com.

[Kashan Jafri]

I have been using this rules approach for a few weeks and it works fine most of the time but weird things start happening if someone uses local presses at the switch quickly (e.g. on/off/on). The related switches may get out of sync and the queued rules/insteon commands may turn the light on/off 5-10s after the last local switch press.

The real solution for this is probably to get the insteonplm binding to act as a scene controller by being able to send group/scene broadcast commands from the PLM. To keep things simple you can use HouseLinc to define the scenes/groups in the modem (MrHouse has this functionality built-in as it can read/write links to devices directly). This already works correctly in openhab using one of the insteon 6/8 key keypads. The keypad acts as a scene controller and my 3/4-way switches are all in sync, but I haven't been able to get the insteonplm binding to send group messages itself without going through a keypad. You can see the relevant insteon commands on page 49 here:

http://cache.insteon.com/pdf/insteondetails.pdf

This is what the insteon hub app (and based on the documentation MrHouse too) use to keep 3-way and 4-way switches in sync. When I used to use the insteon hub, controlling devices directly would act the same way the insteonplm binding does now - only that device would change, and linked devices would not. If you defined a "scene" in the insteon hub app that contains all related switches and used that instead to turn lights on/off, then all 3/4-way switches would remain in sync. Behind the scenes the hub app would be defining a scene/group in the hub/modem and it would be visible if you connected to the hub through HouseLinc.

This group/scene functionality could possibly be exposed as another device type and the item file would specify the modem's group number. This way you still have direct device control that you have now, but also have the ability to control scenes/sent group messages.

To unsubscribe from this group and stop receiving emails from it, send an email to openhab+unsubscribe@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.
Visit this group at http://groups.google.com/group/openhab.
To view this discussion on the web visit https://groups.google.com/d/msgid/openhab/664a3828-8c73-484b-957e-d23249f947fc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Bernd Pfrommer]

Ok, so that's how MrHouse et al do it. Good to know!

One thing I'm a bit puzzled about though: are you saying that when you trigger a keypad button from within openHAB (via modem group broadcast), the keypad then triggers its responders in turn? That's something that Joe Barnum tried to do and it didn't work for him. Would also go counter to my experience that devices usually do not send out group broadcasts unless directly actuated.

About the rules approach: are your rules triggered by command or state change? If you use state change, yes, that will lead to all kinds of screwy behavior b/c openhab is not really suited for real-time response. But if you just multiply the openhab *commands*, the rule should never even run when you toggle the switch manually.

Back to supporting group broadcasts: if we introduce new device types for that (let's call them meta devices for now), would we potentially end up doubling the number of device types then (minus the devices that can't be configured as responders, like sensors)? The question is also then what state (off or on?) to associate with that meta switch. Would almost be easier to add a "group" item configuration like we did for the keypads.

I don't like the way this is heading. It's getting ugly. We have no configuration tool other than houselinc (which I hate because it has a tendency to wipe out the modem database, and Insteon seems to waver on supporting that going forward: the 2014 Hub no longer works with it). Supporting manipulation of the link databases directly in openhab 1.x is out of the question, and I failed on openHAB 2 at the lowest hurdle: getting it to build. Not only that, it seemed to me like the link databases of different devices are not standardized, and are manipulated with different commands, meaning more painful debugging device by device if we wanted to configure the databases from within openhab (or a stand-alone manipulation tool). Even if we provide a config tool to create the modem groups: unless we create the groups under the hood and on the fly like the Hub does, people will be struggling to get the configuration right, and correctly match the modem groups to openhab items.

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab/ec2cc24e-b695-4f1e-8a05-8bc450063fb9%40googlegroups.com.

[Kashan Jafri]

For the rules, yes I was using state change so that would explain the odd behavior. I didn't realize the command trigger didn't respond to local presses. 

Correct, I have a button on a 2334-232 keypad triggering all responders in a 4-way configuration. The key to getting this to work was configuring a scene through HouseLinc as follows:

2334-232 Keypad Button A - Controller & Responder

2413U Modem - Scene 1 - Controller

2477S Switch - Controller & Responder

2477S Switch (load connected here) - Controller & Responder

In my items file i have (where xx.xx.xx are device IDs):

Switch entranceKeypadButtonA "Entrance Keypad Button A Stairs" (allLights) {insteonplm="xx.xx.xx:F00.00.15#keypadbuttonA,group=1,related=xx.xx.xx+xx.xx.xx"}

Controlling this keypad button A through a sitemap or via rules causes the other 2 switches to change as well. I have related items listed but they don't seem to be triggering a poll. The poll works for regular switches and dimmers for me so I am not sure if it is implemented for keypad buttons.

In the debug logs it looks like the binding is already sending a group message to the modem for this case:

21:55:22.826 [INFO ] [.o.b.i.InsteonPLMActiveBinding:122  ] - Item: entranceKeypadButtonA got command ON

21:55:22.826 [DEBUG] [o.o.b.i.i.device.InsteonDevice:170  ] - processing command ON features: 7

21:55:22.826 [INFO ] [.o.b.i.i.device.CommandHandler:148  ] - LightOnOffCommandHandler: sent msg to switch xx.xx.xx to on

21:55:22.826 [DEBUG] [o.o.b.i.i.device.InsteonDevice:351  ] - qe taken off bcast: KeyPadButton3(1:1:4) OUT:Cmd:0x62|toAddress:00.00.01|messageFlags:0xCF=ALL_LINK_BROADCAST:3:3|command1:0x11|command2:0xFF|

21:55:22.841 [DEBUG] [o.o.b.i.internal.driver.Port  :327  ] - writing (500): OUT:Cmd:0x62|toAddress:00.00.01|messageFlags:0xCF=ALL_LINK_BROADCAST:3:3|command1:0x11|command2:0xFF|

I am guessing the keypad is handled differently in the binding code as I couldn't get a regular dimmer switch (F0.00.01) to send these group commands when I added group=X to the items file.

To support group broadcasts I don't think we will need to duplicate all of the device types. We would probably be fine with just a single "meta" device type that can be used for all scenes/groups. You can think of scenes as an abstract collection of various Insteon devices. I believe the only commands supported are on/off/dim/brighten. Even the Insteon hub app only allows these commands to be triggered on scenes.The On level and list of devices/responders are all stored within the scene in the modem. This works well for switches that only have on/off states. For dimmer switches I don't think a scene can respond with an "On" level when polled (since it could be different for each device in the scene), so the Insteon Hub will show the scene only as On or Off, even if you dim or brighten it.

Regarding scene configuration I don't know if it is worth the maintenance effort to try to configure Insteon devices and scenes through OpenHAB. The UDI ISY99i controllers do this and they have dedicated development teams to keep up with all the latest devices and firmware revisions. The same goes for the Insteon Hub App and it appears that MrHouse has taken the better part of a decade to provide the level of Insteon support it has now. There is also yet another version of the Insteon hub that was announced that is supposed to be more developer friendly and support Alljoyn: http://www.insteon.com/insteon-hub-alljoyn/.

[Nathan Stratton]

So I got around to trying this out and it did not work for my dimmers, so I came up with I think a simpler approach that works for me. It collapses everything into one rule by just simply reflecting the command (dimmer value or on and off) to the salve.

rule "Basement_Light_Slave"

when

    Item Basement_Light_Master received command

then

    sendCommand(Basement_Light_Slave, receivedCommand)

end

><>
nathan stratton | vp technology | broadsoft, inc | +1-240-404-6580 | www.broadsoft.com