Added support for FanLinc module, model number 2475F.

[BrianTillman]

Added support for the Insteon FanLinc module, model number 2475F.

My OpenHAB .items file:
Dimmer ManCave_Light_Overhead "Man Cave Fan Light" (ManCave) {insteonplm="xx.xx.xx:F00.00.1C#lightdimmer"}
Number ManCave_Fan_Overhead "Man Cave Fan" (ManCave) {insteonplm="xx.xx.xx:F00.00.1C#fancontrol,group=2"}

My OpenHAB .sitemap file:
Switch item=ManCave_Fan_Overhead mappings=[1="Off",2="Slow",3="Medium",4="High"]

[berndpfrommer]

Brian,

Thank you for your contribution. By and large looking good, but I need to make a few comments to feel important....

1. This one is easy: please remove lines like that:
   //m = null;

2. Now a tougher one: You have configured a DefaultPollHandler for the "FanLincFanControl" feature. That handler works for a light or dimmer, in that it sends a 0x19/0x00 query command. But you already have a 0x19/0x00 query go out to the device, because your "lightdimmer" feature is configured as a "GenericDimmer", which in turn also has a DefaultPollHandler configured. So you are double polling the device with a 0x19/0x00 command, but there is only one message handler (on the GenericDimmer) that actually processes the message.
   Two fixes are possible:
   a) Change to NoPollHandler for the "FanLincFanControl". That's the cheap way out, I don't really like it, because it will mean that the state of the fan speed is unknown to openhab.
   b) Create a new poll handler and set it for "FanLincFanControl", that actually sends the correct query code, 0x19/0x03, see http://cache.insteon.com/developer/2475Fdev-022012-en.pdf on page 1. Then create a message handler that handles the reply correctly. That way the fan speed is polled. Please test that the poll actually does retrieve the state of the fan correctly.

3. Another one related to state of the fan speed: What kind of broadcast messages does the FanLinc emit when you change the fan speed manually? Check the debug log and let us know what you get. Any way that message can be parsed so the fan speed state can be updated? Otherwise the fan state does not update until the next poll happens (and if you choose option a) above, never).

[BrianTillman]

Hi Bernd,
Thanks for the feedback!

I'm traveling this week without access to a suitable development machine. I'll knock out your suggestions this weekend.

Thanks again!
Brian

On Sep 8, 2015, at 12:40 PM, Bernd Pfrommer <notifications@github.commailto:notifications@github.com> wrote:

Brian,

Thank you for your contribution. By and large looking good, but I need to make a few comments to feel important....

1. This one is easy: please remove lines like that:
   //m = null;

2. Now a tougher one: You have configured a DefaultPollHandler for the "FanLincFanControl" feature. That handler works for a light or dimmer, in that it sends a 0x19/0x00 query command. But you already have a 0x19/0x00 query go out to the device, because your "lightdimmer" feature is configured as a "GenericDimmer", which in turn also has a DefaultPollHandler configured. So you are double polling the device with a 0x19/0x00 command, but there is only one message handler (on the GenericDimmer) that actually processes the message.
   Two fixes are possible:
   a) Change to NoPollHandler for the "FanLincFanControl". That's the cheap way out, I don't really like it, because it will mean that the state of the fan speed is unknown to openhab.
   b) Create a new poll handler and set it for "FanLincFanControl", that actually sends the correct query code, 0x19/0x03, see http://cache.insteon.com/developer/2475Fdev-022012-en.pdf on page 1. Then create a message handler that handles the reply correctly. That way the fan speed is polled. Please test that the poll actually does retrieve the state of the fan correctly.

3. Another one related to state of the fan speed: What kind of broadcast messages does the FanLinc emit when you change the fan speed manually? Check the debug log and let us know what you get. Any way that message can be parsed so the fan speed state can be updated? Otherwise the fan state does not update until the next poll happens (and if you choose option a) above, never).

Reply to this email directly or view it on GitHubhttps://github.com//pull/3139#issuecomment-138679105.

[teichsta]

Thanks guys for taking over!

[BrianTillman]

Hi Bernd,
Addressed your comments 1 and 2 (via option b); fan speed state is correctly updating in OpenHAB via polling when changed outside of OpenHAB (the Insteon iOS app in my test case). Commit d18071c.

Now on to 3!

3 messages are received from the FanLinc controller, though I don't think the DefaultDispatcher is invoking a MessageHandler for them (preferably the existing FanLincFanControlReplyHandler). I suspect they key used to lookup the MessageHandler isn't getting set appropriately since these messages are not considered 'MyDirectAck' messages. Since I know little about Insteon communication, I thought it better to ask before marching down the path of adding a new Dispatcher class for FanLinc.

Also, my development environment resides on a physically separate machine from the machine running OpenHab. Do you have a recommended approach to debugging live? -- I'm adding log statements, compiling, exporting the plugin to the OpenHab machine, and restarting my (production) OpenHab instance. Tedious!

Thanks again for the feedback and direction!

Log Data!

1. Newest entries first.
2. Is there a better method to provide log data? -- somewhat hard to read here.
3. I redacted the address for the hub and FanLinc controller out of pure paranoia -- is this data safe to post publicly?
4. I don’t know what to make of the first message (command1 == 0x11).
5. The 2nd message (command1 == 0x19 as expected) appears to always have a command2 value of (0x00 or "Off").
6. The 3rd message (command1 == 0x19 as expected) has a command2 value of the new state (0x55 or "Low" in this example).
7. The 3 messages appear to always arrive in the same order.

I'm thinking we need a method to differentiate the 2nd and 3rd message (perhaps order/iteration), then invoke the existing Fan Linc Message Handler.

2015-09-12 15:35:59 DEBUG o.o.b.i.i.device.DeviceFeature[:250]- 37.08.96:GenericLastTime publishing: 2015-09-12T15:35:59 2015-09-12 15:35:59 DEBUG o.o.b.i.i.d.MessageDispatcher[:123]- defdisp: 37.08.96:GenericDimmer qs:QUERY_ANSWERED cmd: 80 2015-09-12 15:35:59 DEBUG o.o.b.i.i.d.MessageDispatcher[:123]- defdisp: 37.08.96:FanLincFanControl qs:QUERY_ANSWERED cmd: 80 2015-09-12 15:35:59 DEBUG o.o.b.i.InsteonPLMActiveBinding[:522]- got msg: IN:Cmd:0x50|fromAddress:(FanLinc)|toAddress:(Hub)|messageFlags:0x25=ACK_OF_DIRECT:1:1|command1:0x19|command2:0x55| 2015-09-12 15:35:59 DEBUG o.o.b.i.i.device.DeviceFeature[:250]- 37.08.96:GenericLastTime publishing: 2015-09-12T15:35:59 2015-09-12 15:35:59 DEBUG o.o.b.i.i.d.MessageDispatcher[:123]- defdisp: 37.08.96:GenericDimmer qs:QUERY_ANSWERED cmd: 80 2015-09-12 15:35:59 DEBUG o.o.b.i.i.d.MessageDispatcher[:123]- defdisp: 37.08.96:FanLincFanControl qs:QUERY_ANSWERED cmd: 80 2015-09-12 15:35:59 DEBUG o.o.b.i.InsteonPLMActiveBinding[:522]- got msg: IN:Cmd:0x50|fromAddress:(FanLinc)|toAddress:(Hub)|messageFlags:0x25=ACK_OF_DIRECT:1:1|command1:0x19|command2:0x00| 2015-09-12 15:35:58 DEBUG o.o.b.i.i.device.DeviceFeature[:250]- 37.08.96:GenericLastTime publishing: 2015-09-12T15:35:58 2015-09-12 15:35:58 DEBUG o.o.b.i.i.d.MessageDispatcher[:123]- defdisp: 37.08.96:GenericDimmer qs:QUERY_ANSWERED cmd: 80 2015-09-12 15:35:58 DEBUG o.o.b.i.i.d.MessageDispatcher[:123]- defdisp: 37.08.96:FanLincFanControl qs:QUERY_ANSWERED cmd: 80 2015-09-12 15:35:58 DEBUG o.o.b.i.InsteonPLMActiveBinding[:522]- got msg: IN:Cmd:0x50|fromAddress:(FanLinc)|toAddress:(Hub)|messageFlags:0x2F=ACK_OF_DIRECT:3:3|command1:0x11|command2:0x55|

[BrianTillman]

Adding the log data inline with the comment didn't work very well... Here's a pastebin link: http://pastebin.com/qHMSp1G1

[berndpfrommer]

Brian,
-don't know why people erase their insteon addresses, I don't think it's a significant security risk.

• log data is good as you present it. took me a while to realize that it was in reverse time order.
  So you used the Insteon app to change the FanLinc fan switch ... that's not what I meant with "change manually" :). Here's the issue: I really never intended to support two controller programs messing with the PLM modem at the same time. In other words, you should use the hub either with the Insteon App, or with openHAB, but not with both at the same time. The Insteon PLM in many situations requires the control software to know what message it has sent out in order to interpret the return traffic correctly. If the Hub control software sends out a message over the PLM modem, the InsteonPLM binding may get confused by the return traffic.
  I believe your log shows exactly such a situation. The Hub sends out a message, and the binding sees the return traffic. It tries to match the return traffic (which is marked as ACK_OF_DIRECT, meaning the result of an earlier DIRECT message) to a query it sent out earlier, but alas it can't find a match, since that DIRECT message was formed and sent by the Hub, not the binding. You see the dispatcher drop the message because the handlers are in "QUERY_ANSWERED" state, meaning no reply is expected.

I assume the first message the hub sent out was cmd1 = 0x11 cmd2 = 0x55. What you are seeing is the reply from the fanlinc, echo'ing the command received

(Hub)|messageFlags:0x2F=ACK_OF_DIRECT:3:3|command1:0x11|command2:0x55|

Next thing, the Hub queries the dimmer with 0x19/0x00 (see page 1), no idea why

The reply is the dimmer on level:
(Hub)|messageFlags:0x25=ACK_OF_DIRECT:1:1|command1:0x19|command2:0x00|

Finally, it queries the fanlinc status with 0x19/0x03, and we get back

(Hub)|messageFlags:0x25=ACK_OF_DIRECT:1:1|command1:0x19|command2:0x55|

Now that is a bit strange, because I would not have expected cmd1=0x19, because per spec it should be cmd1=db_delta, i.e. a random number. Could just happen to be 19, but small chance. Hmm.
Either way, this is a case (at least per spec) where the return message does not echo the original cmd1. The sending application has to know what was sent out to interpret the return traffic. Not the way I would have designed the protocol. The light switches BTW do indeed send the db_delta junk in the return message instead of echoing the cmd1, so I'm not making this up. It was a royal PITA to work around the missing cmd1 echo.

Long story short: will be a headache supporting simultaneous openhab/hub app coexistence. As it is right now it will sorta work most of the time, and polling will eventually fix the state differences.

What messages do you see when you get out of your chair, walk over, and operate the fan switch directly? I'd expect some broadcast messages to come in...

[BrianTillman]

Ah hah! I see where we missed each other with manually operating the fan: The FanLinc 2475F controller is an in-ceiling unit. There is a physical button on the controller to operate the fan, however it isn't intended for normal use, it's in the ceiling. It also doesn't offer control via an external switch like the Aeotec Z Wave dimmers. http://cache.insteon.com/documentation/2475f-en.pdf

For my specific use, I'll be operating the fan based on data from Z Wave motion and temperature sensors via OpenHab automation rules.

I personally don't see much value to sorting out simultaneous control from OpenHAB and the Hub app. If someone happens to use the Hub app, OpenHab will sync state on next polling interval. I think we're done :)

If you're still interested in the messages sent when the physical button is pressed I'll get them over to you next time I install a unit.

Thanks again for your help! I'm glad we've got this working!

[teichsta]

so can you give me a sign when you thing this PR is ready to be merged? Thanks, Thomas E.-E.

[berndpfrommer]

Sorry, I dropped the ball on this.
I looked over the code and yes, this is good to be merged.

[teichsta]

great @BrianTillman could you please squash your commits into one. The PR can then be merged soon.

[BrianTillman]

@teichsta I goofed and merged several other changes in addition to squashing the two commits as you requested. I've reverted the accidental merge, however, it makes this pull request really ugly. Would you prefer that we close this pull request and I open another, or do you know of a clever way to un-goof this pull? I probably should have branched before making my changes. Apologies for the rookie mistake!

[teichsta]

better create a new one (and close this one). And yes it is definitely good practice to create a new branch for each new feature/pr you are going to send …

[BrianTillman]

@teichsta Thanks! Closing this PR and will open a new one!