I use rules to connect Insteon Keypads to non-Insteon devices. Because of the need to make sure the button and the device have the same, there is a lot of work that goes into programming it, and it doesn’t always work reliably. In particular, you have to double check what’s caused a change, because you want both a change in button status to change the device, and a change in the device status (commanded for example from an Echo) to change the button, but you have to avoid a loop.
Is there any way to use profiles to simplify this and/or make it more reliable?
Profiles within OH are used to keep two like devices at a similar state without having to create rules; common use case scenario are smart light bulbs all dimming to the same values when 1 of them is given a command.
Are you saying you have multiple Keypads you want kept in sync or you want the keep an Echo/keypad in sync? I think its multiple keypads, and you are issuing a command to an Echo.
Are you saying you have multiple Keypads you want kept in sync or you want the keep an Echo/keypad in sync?
Not quite.
I want to use an Insteon Keypad button to turn on/off the Hue Bulb (for example). Additionally, I want the Insteon Keypad button light to update if the Hue Bulb is turned on a different way (e.g. via an Echo).
I can make this sort of work with Rules, but it is not 100% reliable and it requires some careful programming (to avoid getting into a loop). I was wondering if there was a way to do this same thing using Profiles instead of rules and if it would be more reliable.
Instead of OH profiles, it sounds like you want to use mqtt items and run rules based on the state changes on the mqtt broker.
Example (not a expert in mqtt, FYI):
If the Hue Bulb changes then send a command to mqtt item X (for sake of the example).
If X changes then post update the Keypad button.
Something along those lines would avoid rule logic creating loops and you would just need to account for the external sources that are setup to send commands to the Hue bulbs.
The problem comes from wanting it to track both ways.
I want a button press to turn on the light. So I need something (whether it’s profiles, rules, or mqtt) that says “if the button changes state, change the state of the light”. But if the light is turned on another way (e.g. via Echo) I want the button to light up, so I need something that says “if the light changes state, change the state of the button”. The problem is that if you do both of these, they can loop with unexpected results (especially if something gets triggered before the status has actually changed).
I’ve solved this with rules, but was just wondering if Profiles could do the trick in a more elegant manner…
Tracking could be maintained by updating the virtual mqtt items, I don’t have any of the hardware that you are working with. I also skimmed through the Insteon binding doco and did not see any information on updating a keypad, just configuration on pushing out commands.
Another option to consider is posting the rules giving you issues and see if one of the rule gurus can provide a better way to meet your requirements.
I guess I don’t understand Profiles then. I thought that one of the uses of profiles was to have multiple lights, and you could set one light B to “follow” light A, so that if light A is turned on, then light B will turn on.
That’s like what I want to do, except in my case one of the lights is an LED behind a button on an Insteon controller. And I’d also like it to follow in both directions. Is that possible? Does anyone know how profiles work?
I have profiles setup on my OH but for only 2 light bulbs, have you tried adding the profile commands to the item to see what happens?
I have noticed even with profiles after I have a restart on OH, it takes one or two ON/OFFs to get the light dimming to follow one another; but then its rock solid.
I haven’t upgraded to 2.4 yet - if profiles can improve my Insteon Keypad-to-Hue Bulb integration, then it might be worth the effort. Otherwise I may just hold off upgrading until I see a more compelling reason.
@varneyb I struggle with this in my insteon keypad also. I wrote some rules but like you have some sync issues from time to time. I am going to try a post update command.
At the time I wrote the rules I was very new to openHAB. Since all seemed to work ok I have not made any changes. Just last week I purchased a second keypad so I am working through changes now.
I haven’t tried to automate things on the keypad from OH, precisely because of the “button state” problem. I had an additional problem where I couldn’t get button one to work without controlling the load the way I wanted, so went to a different configuration until I can figure that out.
It may be that this is one of the places the ISY device shines, because it has scenes that know how to do these things. I haven’t got one myself, and have been trying to avoid the expense, but on another forum everyone with the ISY described this situation as “easy” and showed config examples of how they did it.
Oddly, on that forum, everyone using Insteon uses the ISY and nobody’s even heard of OpenHAB. My trying to do manual programming of the devices seemed alien to them, when there’s a tool to help.
You are not alone in your struggle, and it’s a tricky situation.
You might get better sync by using a virtual switch for each button, and then having rules on either the button change or the “virtual” switch change that would update the status of everything else. Less loops that way, and then you get a single switch in OH for each button. I haven’t tried this yet, personally, but it’s working well for another cranky device I have.
I have had reasonable success with rules to do this job. I want to play around with profiles but have not done this yet.
I am looking at insteon to mqtt when I transition to a plm from my hub in the coming weeks. They look to have some more features than the binding. Need to read docs more.
Like you I am considering an isy but saving some $$ right now.
As far as I know, the OH integration between the Hub and the PLM will be identical. The Hub, however, may offer some programming and configuration aides that is harder to do manually, much as the ISY will do.
I do wish the Hub didn’t require the link to their website to function any more. That’s the primary thing keeping me from one. I like the features, but do not like the integration and dependence on the external web site. I hope it works great for you!
Danny, would you mind posting some examples from your setup? I’m using the ISY binding, and I see that my 6-button keypad comes up with buttons a through f, plus channels for LoadLevel and PaddleAction. I’m assuming a is the “on” button on the keypad, and f is the “off” button, but that’s just a guess.
Any insight (and code) you can share would be appreciated!
On the Isy setup unfortunately I am unfamiliar with it. I am still on the Insteon hub with plm binding. For that I use Insteon terminal to program everything.
Generically speaking - nothing to do with ISY - remember that 8 key and 6 key keypads are physically identical - only the face plate is changed to make it 6 or 8 keys.
An 8 key key pad has 4 rows of 2 keys
Internally they are labeled as 1,2,3,4,5,6,7,8, but externally they are a (or load),b,c,d,e,f,g,h
On 6 key keypads, buttons 1/2 are ganged together for “On” and 7/8 are ganged together for “Off”
With this, the scene buttons are 3 & 4 in the first row (labeled on the switch’s default buttons as Scene A and Scene B) and buttons 5 & 6 are in the second row (labeled on the switch’s default buttons as Scene C and Scene D).
