Insteon my_own_feature (new I think): onlevel

Add-ons Bindings
1

I’ve been watching development of a couple of other Insteon modem softwares (insteon mqtt in particular). They recently added the ability to change the “on level” of dimmers without turning on/off the light. I spent some time poking around their code and the Insteon PLM code here on OpenHAB. I’ve been able to put together a new “my_own_devices.xml” and “my_own_features.xml” for my Insteon binding that seems to let me control the dimmer on level of my lights!

I think this is new for OpenHAB - at least I haven’t seen it mentioned anywhere on the forms. If someone knows a better way to do this please share it.

my_own_devices.xml looks like:

<xml>
<device productKey="F00.00.91">
     <model>2477G</model>
     <description>Garrett Dimmer</description>
     <feature name="dimmer">GenericDimmer</feature>
     <feature name="manualchange">ManualChange</feature>
     <feature name="fastonoff">FastOnOff</feature>
     <feature name="lastheardfrom">GenericLastTime</feature>
     <feature_group name="ext_group" type="ExtStatusGroup">
          <feature name="ledbrightness">LEDBrightness</feature>
          <feature name="ramprate">RampRate</feature>
          <feature name="onlevel">OnLevel</feature>
     </feature_group>
</device>
</xml>

my_own_features looks like:

<xml>
<feature name="OnLevel">
	<message-dispatcher>DefaultDispatcher</message-dispatcher>
	<!-- handles direct extended message after query -->
	<message-handler cmd="0x2e" ext="1" match_cmd1="0x2e" match_cmd2="0x00" match_d2="0x01" low_byte="userData8">NumberMsgHandler</message-handler>
	<!-- handles direct ack after poll-->
	<message-handler cmd="0x19">TriggerPollMsgHandler</message-handler>
	<message-handler default="true">NoOpMsgHandler</message-handler>
	<command-handler command="DecimalType" ext="1" cmd1="0x2e" d1="0x01" d2="0x06" factor="1" value="userData3">NumberCommandHandler</command-handler>
	<command-handler default="true">NoOpCommandHandler</command-handler>
	<poll-handler>NoPollHandler</poll-handler> <!-- polled by ExtStatusGroup -->
</feature>
</xml>

And an example item:

Number OnLevelCloset  "Closet On Level"  {insteonplm="46.b4.48:F00.00.91#onlevel"}

NOTE: the error below was fixed when I changed all items of Insteon address 46.b4.48 to device type F00.00.91. I haven’t seen any errors for a while after this fix. (Edit October 14, 2018)

I say this “seems to work” because I’ve had trouble during a couple of OH restarts. The error I get is:

2018-09-23 19:06:10.115 [ERROR] [g.insteonplm.InsteonPLMActiveBinding] - item OnLevelCloset references unknown feature: onlevel, item disabled! Known features for F00.00.91 are: dimmer, fastonoff, lastheardfrom, ledbrightness, manualchange, ramprate.

This error is odd to me because on boot the insteon binding correctly loaded my two xml files - if anyone has suggestions about why this could happen and how to prevent it in the future, I’m listening. But for now I’m off to go write rules to change my dimmers to have dynamic on levels based on how high the sun is in the sky!

Edit January 18, 2019: submitted pull request to make this part of everyone’s Insteon features!

2

Great job putting this together! Pretty cool! What does it do ? Is it that when a dimmer is commanded on the dimmer goes to a known level vs 100%

3

Yes - this has always been able to be set locally at the switch (set the light to your desired level, press the set button once quickly) but now I can do it through rules.

The idea is send a number to the item (0-255) and that will be the new on level. That is, the level the light will go to when the dimmer is turned on at the switch. Now any time we go to the closet (or toilet, and eventually our kids room) and turn on the light it will go to a different brightness based on if the rules I will be writing…

1 Like
4

Really cool!! So you could set the brightness based on time then using a rule.

I will love to see the answer to your question. This is a neat feature. What version of oh are you running? I ask because 2.3 had some issues at startup initializatiins and those were fixed in 2.4.

5

Interesting. I’m running 2.3 release. My work around was to stop openhab, make my changes, set the devices to a new fake ID number (F00.00.91) and restart openhab.

That process resulted in no errors and all 5 of my set up on level items working properly.

For anyone who knows a lot about Insteon, I copied the “ledbrightness” feature, changed 0x07 to 0x06, and changed names. I’m unsure is “userdata3” is actually correct - but things seem to work!

1 Like
6

Some comments after a few days running this. I changed my_own_features.xml so that the 5th line has “userData8” (I had it as 7 before). That’s fixed the polling for the on level.

Additionally it seems like it might be important to use the same ID number (F00.00.91 in my case) for all items of the same hardware type.

I’ve done those two things and I think things are working properly.

@Bernd_Pfrommer - are you still around? Do you have any comments on this?

7

I don’t think it matters about having all hardware types have the same ID number. The binding doesn’t have any idea what its talking (or listing) to other than this number. Essentially it just shoots some data down the line and listens for some response. No different than if the HW was actually different. Now, if you have multiple items referring to different features on the same device, I agree.

Curious if you’ve looked at InsteonTerminal? I’m 99% sure that this feature is already implemented there. Of course you cannot use InsteonTerminal to change things dynamically thought OpenHAB like what you’ve implemented, but you can look at the python there to see how the same action is being done.

8

I’ve been watching development of Insteon-mqtt on github and they recently implemented this. I compared their LED level to the openhab LED level and made the changes they made to get onlevel working. I will need to take a look at Insteon terminal again to see if I can get any more ideas. And yes, I have multiple items referring to the same Insteon device (obviously - I use the dimmer, fastonoff, and now onlevel).

Thanks for the tips - I’ll keep progress updated here in case it works great forever and others want to copy.

9

Checking in with some follow up in case anyone’s been watching this - I’m 2 weeks in with the code above and everything is working great. The on level even polls correctly!

Some comments:
-it appears that Insteon needs all of the items with the same Insteon address to also have the same device id number (in my case F00.00.91). If you have a single switch referenced with two device ids then you’ll probably get errors.
-I have my on level rules set to run shortly after sunrise and shortly before sunset - but with a 5 second delay between each dimmer, Insteon doesn’t seem to respond well to multiple commands coming through at the same time.

I’ve been running these rules for 2 weeks now with a rock solid openhab (2.3 stable release) and no Insteon errors in that time. Hopefully someone out there finds this useful and is able to add onlevel to their dimmers!

1 Like