[Release] Insteon direct PLM dimmer/switch driver

[Updated] October 6, 2018

Great news for Insteon Hubitat users! A DTH from the other hub has now been ported by @cwwilson08 for direct HTTP control of Insteon dimmer modules, lightbulbs, switches and relays. No Node.js server is required!

This Hubitat driver takes advantage of the Insteon PLM built into their hubs, allowing direct control via HTTP GET. This driver supports the internal Ramp Rate of the device during ON/OFF and dimming operations. Lights will transition smoothly at their pre-defined ramp-rates in all cases, giving the nice appearance we've come to expect from Insteon.

Features

Ramp Rate - The built-in Ramp Rates are supported for individual devices, but user definable Ramp Rates are not supported with the Insteon PLM. Therefore, the Fade box in the driver does not serve any purpose and may be left blank.

Fast ON/OFF- User selectable support for Insteon Fast ON/OFF to allow insteon dimmers to turn on or off in 0.1 second. This is useful for using dimmers, dimmer modules and dimmable outlets to turn on devices quickly, such as electronic that would otherwise be damaged by a slow ramp up and down or compact florescent lights that might be damaged by a slow ramp up or down of the dimmer circuit.

Refresh - The built in refresh function has been removed due to issues with trying to refresh more than one driver. Even if the refresh times are staggered among the drivers, the refresh became erratic and unreliable. If you must have refresh, use Rule Machine to creates a periodic triggered rule and do not refresh more than one device. Changes to the driver will update instantly, but changes at the devices outside of Hubitat, such as dimmer adjustment, Micro Module latching or momentary modes, or response to Insteon Load Sensing feature found in LampLinc plug-in modules and wall outlets will not be updated in Hubitat unless refresh is used.

If you require refresh for more than one Insteon device, the HTTP Insteon switch/dimmer driver for use with Express Server is recommended. The built-in refresh setting for that driver has also been removed due to issues, but unlike the direct driver, the HTTP driver for Express Server can use Rule Machine to refresh multiple devices at once without issue.

[Edits]

10-6-2018

  • Built-in refresh removed due to issues when trying to use multiple Insteon direct drivers with refresh enabled.

9-14-2018

  • New code adds user definable refreshed rates within the driver settings page. NOTE: Driver may be set to "No Selection" for refresh rate and RM used instead for custom refresh rates.

  • Added Fast ON/OFF enable and disable option.

3 Likes

I'm so excited about this! Anyone who has used the Insteon Switches knows how much better (more solid) they feel than the z-wave switches on the market. When you press the paddle, it actually pivots instead of flexing.

I'm kind of surprised that the integration was done with the hub when there's a USB PLM available. I happen to own both, so I'm still good with this.

To be clear, this is a custom integration, not an official Hubitat integration. There's isn't a way at present to get data from the Hubitat Hub to the USB PLM. Wouldn't be possible to just plugin the PLM and use it without changes to Hubitat firmware. Next best is support via HTTP direct so there isn't a mandatory intermediate server.

There are limitations to what can be done via HTTP vs the official API, and it too has its limits, so some creativity is required. The most flexible method at the moment is Homebridge with the Insteonlocal plugin and control via Express Server. There may be an Express Server only version available soon, for those that do not want or need HomeKit support.

We are working on a method to improve the Express Server driver to also support smooth dimming, but this is still in development.

Just wanted to take a second and give kudos to @SmartHomePrimer. He has the patience of Job. Without his patient and thorough testing I would not have been able to get this done. As I have none of the hardware except the Hubitat hub.

1 Like

Thanks Chris. I see my part as small. I appreciate your commitment to a driver for a system you don't even own. So helpful to Insteon and Hubitat owners. I'm glad I could offer my time and patience.

I get the following errors when I've added a device:

dev:9452018-10-06 17:01:42.517:errorjava.lang.StringIndexOutOfBoundsException: String index out of range: -2 on line 229 (getBufferStatus)

dev:9452018-10-06 17:01:42.505:errorsomething went wrong: groovyx.net.http.HttpResponseException: Unauthorized

Says unauthorized but I've checked the user and pass, it matches what's on the bottom of the hub. For url I only put in ip, no http, etc. Any ideas?

It is hard for me to troubleshoot as I do not own one of these devices.

Do you use the insteon app? Have you tried the user name and password from it?

I'm blind apparently. One of the letters on the bottom of the hub was transposed, even though I read it 4 times. It works great now, thank you!

1 Like

There seems to be some issues with having the refresh set in the driver. @SmartHomePrimer could not get multiple devices to work right. I planned to remove this from the driver and just rely on rm for refresh.

1 Like

Yeah I just saw this as well, says wrong device. So RM should work if I set it to do a refresh?

[dev:967](http://10.54.25.34/logs#dev967)2018-10-06 17:38:34.729:errorjava.lang.StringIndexOutOfBoundsException: String index out of range: 28 on line 235 (getBufferStatus)

[dev:967](http://10.54.25.34/logs#dev967)2018-10-06 17:38:34.722:debugParsedBuffer: 02622D38440F190006

[dev:967](http://10.54.25.34/logs#dev967)2018-10-06 17:38:34.720:debugBuffer: 02622D38440F1900060000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000012

[dev:967](http://10.54.25.34/logs#dev967)2018-10-06 17:38:32.082:debugcommandsent

[dev:967](http://10.54.25.34/logs#dev967)2018-10-06 17:38:32.035:debugRefreshing..

[dev:967](http://10.54.25.34/logs#dev967)2018-10-06 17:38:20.813:errorjava.lang.StringIndexOutOfBoundsException: String index out of range: 28 on line 235 (getBufferStatus)

[dev:967](http://10.54.25.34/logs#dev967)2018-10-06 17:38:20.806:debugParsedBuffer: 026230A0D60F190006

[dev:967](http://10.54.25.34/logs#dev967)2018-10-06 17:38:20.803:debugBuffer: 026230A0D60F1900060000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000012

[dev:967](http://10.54.25.34/logs#dev967)2018-10-06 17:38:18.775:debugcommandsent

[dev:967](http://10.54.25.34/logs#dev967)2018-10-06 17:38:18.740:debugResponse is for wrong device - trying again

[dev:967](http://10.54.25.34/logs#dev967)2018-10-06 17:38:18.739:debugParsedBuffer: 02622D38440F19000602502D38444E8966250200

[dev:967](http://10.54.25.34/logs#dev967)2018-10-06 17:38:18.737:debugBuffer: 02622D38440F19000602502D38444E8966250200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000028

[dev:967](http://10.54.25.34/logs#dev967)2018-10-06 17:38:16.709:debugcommandsent

[dev:967](http://10.54.25.34/logs#dev967)2018-10-06 17:38:16.665:debugResponse is for wrong device - trying again

[dev:967](http://10.54.25.34/logs#dev967)2018-10-06 17:38:16.664:debugParsedBuffer: 02622D38440F19000602502D38444E8966200200

[dev:967](http://10.54.25.34/logs#dev967)2018-10-06 17:38:16.661:debugBuffer: 02622D38440F19000602502D38444E8966200200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000028

[dev:967](http://10.54.25.34/logs#dev967)2018-10-06 17:38:14.616:debugcommandsent

Give it a try and let us know.

To this point only one user has tried this driver. The problem is coming from the fact that it takes two calls get the status. When the calls start overlapping the buffer gets filled with the wrong data.

@SmartHomePrimer can likely guide you a little better here. I had an idea to chain a few RM actions together to have it refresh the devices sequentially. I believe he said he had it working pretty well from a single rule...

Ok cool, that's basically the same issue we faced with ST, until I got an API key and an app was made for that. However I just got a new hub as mine died (free replacement!) but the API key no longer works!

Looks like RM rules give the same log results. I'll just add checks to my other automations, I only have three remaining Insteon lights that need control.

Thanks for working on this, one less piece I need in ST!

1 Like

Try staggering refreshes. Or like I mentioned chaining a couple refreshes together with delays. I believe this is the key.

Staggered two of them, same thing, one is set to 10 seconds, the other 12. @SmartHomePrimer did you get this working?

Absolutely do let us know if you find different results. I've no idea what "Response is wrong for device means". I always see that. It's in the driver. Chris, what this for?

What I've ended up with is a combination of the two drivers. I like the ability to have direct control from the HE hub, but if you control a light switch outside of HE, there's no update. If we used the built-in driver update it works, but when you add a second device with the same direct driver and you set it to update, even if it's not the same frequency, it causes unresponsiveness, delays and erratic refresh. So I'm only use the direct driver for devices that I will not be controlling outside of HE (I don't use the Insteon app except for device setup).

For devices that need a refresh because I'm going to control them from the switch sometimes, I'm using the HTTP driver with the Express Server from the Insteonlocal Homebridge plugin. SCOTT KUESTER has written a standalone express server now, but it's lights only at this point.

1 Like

No. Didn't work.

Well more it less it is getting a valid response but for a different device. The buffer can only hold the status of one device at a time. First call fills the buffer with the requested data. The second call reads that data and we parse it for status. So it rejects it and tries to call again. In the meantime the device that had its refresh intercepted is likely going to call for the refresh again as well. So on and so forth. They just battle back and forth.

The direct drivers work great without refresh. For the HTTP express server driver, I can use periodic as the trigger on a 10 second interval and refresh all the express server drivers at once, no problem, but when we tried with the built-in, it caused a weird delay with one of my rules, where if I added even a 1 second delay to the rule, it became 30 seconds. Once I turned off the built-in refresh of the HTTP Express server driver, it immediately returned my rule to normal function.

1 Like

Is this direct hub plugin still active? I am getting confused between this thread and a more recent one that utilizes a lightweight node.js middleware.

Happy New a Year!

Both still work. The one that utilizes the node.js apps is much more capable and refined however.

We changed its title to Beta, but have never had any of the issues that prompted that change, which were based on feedback from another user. I’ve been using this since we released it, and my experience has been very stable. One of my most stable integrations in fact.

1 Like