Background: I’m using OpenHab2’s habpanel for my UI and my lighting is handled by insteon hardware. I have several lighting scenes that are controlled by some on/off buttons (custom widgets). See sample screenshot example.
When a scene button is pressed the related insteon commands take 10 - 30 seconds to complete (classic popcorn ritual). During the insteon traffic a BUSY message appears on the scene’s button; This prevents repeated pressing while the system is sequentially sending the scene commands to the insteon devices.
My brute force method to handle the BUSY message involves a “command busy” .rules file that detects ALL insteon item commands. Traffic to ANY insteon item sets a global Number flag (defined in my .items file). When the flag is set the BUSY message appears in the UI. A createTimer() function in the .rules file disables the busy message after all the insteon traffic is completed.
Everything is working as intended, but I would like to improve on how I detect the insteon item traffic. Currently the .rules file has an instance for each insteon item. I check for all trigger variations (Item received command, Item received update, and Item changed).
For example, the Garage Lights insteon item trigger (in the .rules file) is like this
rule "Command Busy"
when
Item GarageLights received command or
Item GarageLights received update or
Item GarageLights changed
// additional items go here ...
then
The trigger list handles a couple dozen devices. This method is a bit clumsy; What I would like to do instead is trigger on any ItemCommandEvent, sort of like a wild card. That is to say, rather then list each item I would prefer something more code efficient like this:
rule "Command Busy"
when
Any ItemCommandEvent changed
then
Is this possible? For example, it would be ideal if I could use an existing system variable that has the status of the insteon command buffer. Or any other magic like it.
Curious how you are handling these devices. Do you have them in an openHAB group and then you are telling no openHAB to turn on/off that group?
If you created an Insteon scene then used openHAB to trigger that scene, all the lights would trigger in parallel rather than serially. This would greatly speed up your command and probably eliminate the need for this “busy” rule all together.
You are correct, I created groups in my .items file for the scenes. I realize it is an old-school sin to do it this way, but I couldn’t figure out how to use habpanel to remotely manage native insteon scenes. Does habpanel support this method?
I’ve done the manual scene programming method: visit each insteon device, pull tabs, press buttons, rinse, repeat. Not a big fan; So my lazy way of managing the scenes is by using the habpanel groups. But if I can create native insteon scenes from openhab2 then I’m game! Any pointers on how to do this?
Not a sin to do it this way, just slower on the trigger. Setting up the insteon scene can be painful, but it is very slick once you get it set up. In my opinion worth the trouble.
You don’t have to go to each device to create a scene, you can use the insteon-terminal. It does have a learning curve (as does understanding the insteon scene concept and groups etc), but it is a very great tool to get at the low level hardware stuff on your insteon devices. This is how you can get the most out of the investment you made in the hardware.
I don’t use habpanel, but I highly suspect that it can support anything that openhab can. Once you have the insteon scene setup, you can trigger it with the group number of the scene using this:
So lets take your indoor lights for example. Basically you create an insteon Group like say “9”. You make all of the devices you want to respond to the “Indoor Lights” scene responders to the modem on group “9”, and then make the modem a controller for each device on group “9”.
Thanks for the practical advice. Looks like I need to install insteon-terminal and figure out how to use it.
I’m not sure when that will happen because I have a lot of other things to finish: Timer schedule rules, finalizing the UI screens, and incorporating rtlamr for power consumption monitoring are high on the to-do list.
