[OBSOLETE] Insteon Hub 2244 and 2245 Dimmer and On/Off Plugs/Switches/Bulbs

I have the latest DTH installed (Last Modified Date : 2017-5-10) I can control the devices perfectly, but any refresh, either manually or timed, just shows the devices as off.

Here’s a sample ST log extract for an Insteon LED that is currently on 100%

 5:33:34 PM: debug Device is off...
 5:33:34 PM: debug Level: 0
 5:33:34 PM: debug Status: 01
 5:33:34 PM: debug Response is for correct device: 20127C
 5:33:34 PM: debug ParsedBuffer: 026220127C0F190106025020127C33B849200101
 5:33:34 PM: debug Buffer: 026220127C0F190106025020127C33B849200101000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000028
 5:33:32 PM: debug [uri:http://[username]:[password]@[externalIP]:[port]/3?026220127C0F1901=I=3]
 5:33:32 PM: debug Polling..
 5:33:32 PM: debug Refreshing..

Here’s an off state 0%

 5:40:02 PM: debug Device is off...
 5:40:02 PM: debug Level: 0
 5:40:02 PM: debug Status: 01
 5:40:02 PM: debug Response is for correct device: 20127C
 5:40:02 PM: debug ParsedBuffer: 026220127C0F190106025020127C33B849250101
 5:40:02 PM: debug Buffer: 026220127C0F190106025020127C33B849250101000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000028
 5:39:59 PM: debug [uri:http://[User]:[Password]@[IP]:[Port]/3?026220127C0F1901=I=3]
 5:39:59 PM: debug Polling..
 5:39:59 PM: debug Refreshing..

and a 50% state

 5:38:36 PM: debug Device is off...
 5:38:36 PM: debug Level: 0
 5:38:36 PM: debug Status: 01
 5:38:36 PM: debug Response is for correct device: 20127C
 5:38:36 PM: debug ParsedBuffer: 026220127C0F190106025020127C33B849250101
 5:38:36 PM: debug Buffer: 026220127C0F190106025020127C33B849250101000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000028
 5:38:33 PM: debug [uri:http://[user]:[password][IP]:[Port]/3?026220127C0F1901=I=3]
 5:38:33 PM: debug Polling..
 5:38:33 PM: debug Refreshing..

Is this down to Insteon just not reporting the state correctly?

Just so this makes sense to you -

In the hub, there’s a file called buffer.xml, it refreshes every so often, I think you need to call a script to force it to refresh (it should be here in the handler), but it should refresh automatically. In your buffer file, it looks like the status was requested, but it was waiting for the actual status to come in to report it.

The output of the file looks like this:

026220127C0F190106025020127C33B849250101000000
  • 02 - Start - All commands start with 02. It is the ASCII code for start of text.
  • 62 - Type - The type coding for a send message command.
  • 20127C - ID - The ID of the Insteon device.
  • 0F - Flags - The flags for this message. All standard message commands should have 0F for the flags.
  • 19 - Command 1 - The command 1 is the command number telling the device what to do. In this case, request the status
  • 01 - Command 2 - The command 2 is the command parameter. For this command, it is the light level.

I do see another piece of info in your buffer asking the light to be set to 72%… I believe it’s here: 20127C33B8

I think this device handler could use a little bit of work, I’ll try and take a look at it when I get some time.

1 Like

Are you able to share the Insteon API docs with me? I’ve just finished coding a DTH for a Raspberry Pi controlling two garage doors with contact switches so getting more familiar with the ST coding side.

Happy to fork the Github project and add anything I can.

Edit: Found some docs … from the returned buffer:

0262 Pass through Command to PLM
20127C Device ID to Control
0F Flags Byte (Constant)
19 CMD1
01 CMD2
06 PLM Says got it
0250 From PLM Insteon Received
20127C From this device
33B849 To (ID of PLM/Hub)
25 20 = ACK + 5 = hop count
01 CMD1 The command the device received
01 Cmd2

Returned ACK message will contain the LED Bit Flags in Command 2.

Not sure how 01 reflects the LED bit flags - the value seems to not change even when the brightness of the bulb has been changed.

Note: The timing will be such that even if you see the 0250 in the buffer you are not guaranteed that the rest of the data is in the buffer yet.

Could it be a timing issue here - that we’re polling the buffer too soon?

EDIT 2:

Since I also have an ISY connected, I took a look at the commands that are being sent when I query a device status. The LED lamp here is set to 21% brightness.

Sat 12/30/2017 09:06:18 AM : [INST-TX-I1  ] 02 62 20 12 7C 0F 19 00
Sat 12/30/2017 09:06:18 AM : [INST-ACK    ] 02 62 20.12.7C 0F 19 00 06          LTSREQ (LIGHT)
Sat 12/30/2017 09:06:19 AM : [INST-SRX    ] 02 50 20.12.7C 2F.B8.01 27 01 35           (35)
Sat 12/30/2017 09:06:19 AM : [Std-Direct Ack] 20.12.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=1
Sat 12/30/2017 09:06:19 AM : [D2D EVENT   ] Event [20 12 7C 1] [ST] [53] uom=0 prec=-1
Sat 12/30/2017 09:06:19 AM : [  20 12 7C 1]       ST  53
Sat 12/30/2017 09:06:19 AM : [D2D EVENT   ] Event [20 12 7C 1] [OL] [153] uom=0 prec=-1
Sat 12/30/2017 09:06:19 AM : [  20 12 7C 1]       OL 153
Sat 12/30/2017 09:06:19 AM : [D2D EVENT   ] Event [20 12 7C 1] [RR] [23] uom=0 prec=-1
Sat 12/30/2017 09:06:19 AM : [  20 12 7C 1]       RR  23

You’ll notice that the initial TX message uses 19 00 for the commands, not 19 01. I changed the getStatus() URL to use that command and all works great now!

uri: "http://${settings.username}:${settings.password}@${settings.host}:${settings.port}/3?0262${settings.deviceid}0F1900=I=3"

  9:09:51 AM: debug Device is on...
  9:09:51 AM: debug Level: 21
  9:09:51 AM: debug Status: 35
  9:09:51 AM: debug Response is for correct device: 20127C
  9:09:51 AM: debug ParsedBuffer: 026220127C0F190006025020127C33B849250135

Thanks for catching this! Merged your PR. These are the developer references that I use:

Insteon Developer’s Guide
Insteon Command Tables

Once you get the URL format down, the command tables are the most helpful.

Thank you @kuestess and @idealerror for the work you’ve done.
I realized after going through your solution it still requires opening a tunnel into my local network, which is a big no-no in my book :slight_smile: So I’ve decided to refactor the code a bit and make it run locally and poll Insteon from the hub itself using only hubAction. The problem with it was that multiple device can not have the same ip:port as their networkDeviceId. So I recreated the solution as a composite device, have handlers for Insteon Hub which creates child devices for all my switches/dimmers. Yes, for now I have to type and maintain my devices in code, thats the price I am willing to pay for now. In case someone will find it useful:

Hub:

Switch:

So very nice to have Insteon outside of that beige box in so many ways now. Thanks so much @ethomasii, @idealerror and @kuestess!

Scott, between this and homebridge-platform-insteonlocal, you’re really helping my 2245 break out of its shell!

This is particularly nice because, thanks to all the guys that did the work on the LutronPro Caséta v1 project, and the great work by the developers at Stringify, we can now control pretty well anything with Pico remotes too. Now if we just didn’t have to rely on that cloud connection…:thinking:

@SmartHomePrimer Glad you’re enjoying it! Both this DTH and the homebridge-platform-insteonlocal plugin were fun to write!

1 Like

@kuestess @finik Have either of you gents looked into the Hubitat? I’ve tried a few hacks of your work here, but lack of composite device support is killing my meager attempts.

@michaelahess Unfortunately not planning to look at it any time soon, just got into SmartThings lately, can’t justify jumping on another platform now :slight_smile: But what is the problem, maybe I can help? Why do you need support for composite devices there? The original reason I ended up using composite devices was I needed a way to share the same networkDeviceId. But my solution has evolved since my last post:
a) I’ve morphed the parent device handler into a smartapp
b) Since smartapp has no deviceId, I actually found an alternative way of using HubAction that does not involve setting own networkDeviceId and sharing a common parse(). Instead $ip:$port is passed directly into HubAction, and response is obtained through callback. Thus, even though I am still using that parent-child construct, it is not really required and it can be refactored (the request/response parsing moved from smart app into a device handler).
See my current setup here:
DeviceHandler:

Smart App:

1 Like

I’m not a programmer so refactoring is foreign to me. :slight_smile:

I did update the code to get it on the Hubitat, but since it doesn’t support composite devices it errored at:

parent.childOn(device.deviceNetworkId)

And the SmartApp errors out at me on when saving on this test switch I added:

No signature of method: app15184000626201106757573.addChildDevice() is applicable for argument types: (java.lang.String, java.lang.String, null, java.util.LinkedHashMap) values: [Insteon Switch, 2D376F, null, [label:Living Room Lamp]] on line 621

Which makes sense I guess. I see the parent.child references throughout but wouldn’t know where to begin to modify them.

Hi All,

Thanks for the great work on this DTH. I’ve installed it and have it working, however, it’s viewing my dimmable Insteon device as an on/off switch, and I can’t figure a way to fix that.

Any ideas?

Tap on the device name, then tap on the percentage. As long as you have the correct DTH for your dimmable device, you will be able to adjust the brightness.

Thanks for the reply! I installed the latest insteondimmer.groovy from idealerror and kuestess, and my Insteon dimmable switches (InlineLinc) have the dim percentage greyed out and un-tappable. They turn on and off fine, they just don’t dim.

Maybe I missed something simple to specify the DTH as dimmable?

@macinsteon The DTH itself is what tells SmartThings that the device is dimmable, so assuming that you have the insteondimmer DTH set for your device, I’m not sure what would cause the dimming functionality to be greyed out. Maybe double check that the code you pasted in has ‘capability “Switch Level”’ in it.

@kuestess - thanks for helping. Sure enough, I do have ‘capability “Switch Level”’ listed under the definition. Is there any way to “force” it?

With the changes coming to smartthings this app (which I really depend on) will no longer work.

I assume this will require a rewrite to be hosted on an amazon server or at my house

I will go on record and say this is the ONLY custom device i currently use and would GLADLY pay for something that will work.

For the developers - i assume you have seen this coming. Have you given any thought on how you will transition?

I Abandon ship! There’s a better path on the rise.

Not wanting to buy another hub if I was going that route I could do this with a raspberry

I was more wondering if the developers had a plan as this is only thing I couldn’t do without.

I get it. I didn’t enter into the decision lightly. I think there’s a big misconception still about what Hubitat is. Not trying to sell you, but I do want developers to be interested enough to want to come along. Many developers for ST have already joined and more are coming along by the day.

It runs on Groovy and that’s a significant incentive when you consider how it lowers the bar to porting apps and DH over. ALL of your automations can run without the cloud. Your lights don’t need the cloud, pico remotes don’t need an additional server, Hue integration doesn’t need the cloud, and Insteon could have the same benefit. Fast reaction and no cloud or internet outages will have an effect.

Yes, anyone can buy a PI and load HA or OH, but that’s comparatively a lot of work, and frankly near the same cost when you consider having to add Zigbee and Z-Wave support. Then consider that it’s entirely up to you and community when something doesn’t work, instead of a paid support team behind it.

I hear ya Doug. I am interested in whatever works that doesn’t require me to learn a lot of coding (I have cancer and a lot of my time is spent in hospital)

That’s the one benefit of Smarrthings. It was plug and play with groovy and almost everything else I had was supported out of the box.