@TD22057 Yeah, it’s username/pass, so probably my issues are related to the bug. I’ll wait until the fix is out and resume testing 
Really cool stuff 
@TD22057 Unfortunately it only uses a web api so have to poll the 2245 hub periodically for receiving.
I’m doing this in the network event loop. The polling interval is one item I hope to get more testing on.
So far I have only tested with a single LampLinc Dimmer device but have messages passing back and forth successfully. Can use the insteon-mqtt commands to turn the LampLinc device on and off. Can also receive on and off events initiated at the LampLinc device and they get published to MQTT. Have also been able read the links database from the device and see that the json files are created.
@wmaker Did you see this: https://krkeegan.com/technical-inspection-of-insteon-hub2-2245-222/? It has some info that might help you. If it were me, I’d just spend the $65 and get a PLM modem (%20 off at smarthome right now) - it’s going to be more reliable and work better than polling the new hub I think.
FYI 0.6.2 has been released with some bug fixes.
Additions
- Added leak sensor heartbeat reporting support (thanks @djfjeff).
- Added get_engine() command to find the Insteon device engine revision (thanks @krkeegan).
- Added automatic message de-duplication (thanks @krkeegan)
Fixes
- Fixed a bug where the MQTT client might close in an area that triggered an exception instead of a reconnect (Issue #32).
- Fixed bug where the KeypadLinc was using the wrong handler for input MQTT scene simulation commands (Issue #34).
- Fixed bug where the FanLinc would not report speed changes at all (Issue #37).
- Fixed issues with the leak sensor topic documentation (thanks @djfjeff).
- Fixed a bug in the command line script that would not read the MQTT user name from the config.yaml file (Issue #59).
2 Likes
Hi @TD22057 Thanks for this. Yes this covers my understanding of the 2245-222. In the end I may get a PLM modem, but for now I’ll continue investigating insteon-mqtt with the 2245 to see how well (or badly) it works.
By the way, I do want to say thanks for all your work on this!!
FYI - I’ve added an enhancement request to add hass.io support for those of you who want to track any progress on that: https://github.com/TD22057/insteon-mqtt/issues/63
2 Likes
Hey @TD22057 - I’m working on getting my house automated - at this point I’ve got a combination of Homekit devices (siri through homepod is our main way to interact, since it’s easy enough for my 3 year old) and HA on hassbian. I’ve got things running pretty well but I’m looking for fixes with 2 of my complaints, I’m wondering if this is the magic ticket.
My 2 problems are:
-Insteon devices update sequentially (my plm waits for light 1 to turn on before light 2, etc) which can take a while to get through my whole house (about 30 insteon switches at this point)
-HomeKit commands like “set to 20%” go to through the system and put the light at “full bright” for a second or so before ramping down to 20% like I asked
Any chance this project can deal better with these issues and replace the Insteon PLM component in HA?
@crxporter Yes - it should work fine for those. For item 2, it will set the level to whatever you want - no multi-commands, no full brightness. For item 1, it depends on what you’re doing. If you want to turn all the lights on, then you can send an “all lights on” broadcast command (I forget the exact form - it might be a group 255 on broadcast). If you want to turn on a specific group of lights (like say 25 of them), then you can use the command line tool to create a modem virtual scene with those 25 lights and then issue a scene command to turn them all on or off at once by making that scene a switch in HA. Otherwise, if you have an automation in HA that loops and sends a series of “turn light 1 on, turn light 2 on, …”, it will have to iterate through them which does take time. But at least my library does it as fast as the PLM modem will allow.
I’ve got a lot to learn about to make this work. The virtual scene sounds like exactly what I want to do.
Now I just need to figure out how to make a virtual scene.
…and how MQTT works…
There are some command line examples for scene creation here: https://github.com/TD22057/insteon-mqtt/issues/24. Then look at config.yaml under the modem section which has an example for creating a switch in HA to trigger the scene.
Is there any way to detect a double-tap on a switch? Ideally I’d like to be able to use one of my 8-button scene switches to turn on a fanlink: 1 tap = on low, 2 taps = on medium. Once on, 1 tap = off.
@Juggler see https://github.com/TD22057/insteon-mqtt/issues/66. I don’t think you can link a double click to a specific state in Insteon so you’ll have to do to it HA w/ an automation. So that would mean having the fast event (Insteon double click) be sent to HA as an event.
I think it’s probably trivial on the Insteon side. But it’s not obvious how to represent the fast option on the HA side since fast isn’t a state - it’s just an event. So it doesn’t work well as a switch or a sensor (there is no on/off state). I can’t seem to find a HA MQTT component that is just an event that can be triggered. Using MQTT sensor with force_update=true might be the best option.
Any other ideas anyone?
Funny that 2 of us came to the same question at the same time. I don’t have any background in MQTT, but am happy to test code.
Great work… thank you!
@Juggler and anyone else who wants fast on/off support (double click), please check out the github issue to discuss how this should work and how fast on/off should be sent to/from HA since they are slightly different versions of the same commands that already exist on the switch.
I have a few Insteon On/Off wall switches that aren’t connected to load, which I use to control some hue lights/groups. When I initially added the switches to my insteon-mqtt config.yaml file, I put them in the dimmer section. I decided to move them to the switch section, but it appears though insteon-mqtt still thinks they’re dimmers.
$ /opt/insteon-mqtt/bin/insteon-mqtt config.yaml print-db 'xx.xx.xx'
Commanding Dimmer device xx.xx.xx (chandelier switch - downstairs) cmd=print_db
xx.xx.xx (chandelier switch - downstairs) device database
DeviceDb: (delta 0)
0fef: yy.yy.yy grp: 1 type: CTRL data: 0x03 0x1f 0x00
Unused:
0fdf: 00.00.00 grp: 0 type: RESP data: 0x00 0x00 0x00
0fe7: 00.00.00 grp: 0 type: RESP data: 0x00 0x00 0x00
0fff: 00.00.00 grp: 0 type: RESP data: 0x00 0x00 0x00
Last:
0fd7: 00.00.00 grp: 0 type: RESP data: 0x00 0x00 0x00 (LAST)
GroupMap
1 -> ['yy.yy.yy']
I tried running the following…
$ /opt/insteon-mqtt/bin/insteon-mqtt config.yaml refresh 'xx.xx.xx'
$ /opt/insteon-mqtt/bin/insteon-mqtt config.yaml refresh-all
…but that didn’t seem to help.
Any tips for updating the database? I see there are db-add and db-delete commands. If that’s would I should be using, I’m not sure what the proper usage would be.
Ugh. Sorry, all. A reboot seems to have fixed the issue. I should have tried that before posting. =/
Yes, that reboot - and the desire to avoid the amount of time that it takes - can hide demons.
For the record - a reboot makes no difference to the insteon-mqtt server. The only thing I can think of is that it’s running it as a service and it’s not being fully shut down and restarted. If anyone ever runs into this type of issue, I’d recommend stopping the service, check that it’s stopped (ps -ef | grep insteon) and then run the server manually which makes it a lot easier to debug things until you get any config inputs ironed out.
Good point, the RESTART I was referring to is HomeAssistant and NOT insteon-mqtt (which I have on separate computers for now because HomeAssistant is just for testing “on the side”),
I do not have to reboot insteon-mqtt.
I was assuming @mattcantu was referring to rebooting HA.
insteon-mqtt picked up the changes after I rebooted the Pi. In hindsight, as TD22057 pointed out, I could have stopped/started the insteon-mqtt service instead.