This particular one isn't. 
1 Like
That might be the mystery of why people have said that changing from "lightbulb" to "dimmer" worked, when in fact it probably had nothing to do with it. Debug logging is always ON when a device is first created, but it automatically turns off after 30 min to prevent people from forgetting about it and creating unnecessary logging.
It's probably been a coincidence all along. I have mine set to "lightbulb". Always have and it's always worked fine. I manually turn off debug logging when I create a device and only turn it on when and if I need it.
@ChudeMcD Thanks for the notes. I have updated the instructions and hopefully it will go a little smoother for the next person that tries it.
Hope you enjoy the drivers Chris built. He worked very hard to make them as capable as they are, and it's been quite a joy to be able to keep my Insteon devices and use them with Hubitat. They remain some of the most solid performing and reliable devices on my Hubitat Elevation hub.
I tried to add a second device, and it worked, but the process was a little janky. Logging was already disabled, but it wouldn't load and it kept closing the WebSocket connection like before. I enabled it and disabled it, and then it took a couple presses of the Initialize button to work, but it finally fetched the Insteon device ID and created the device. I have about 40 devices to move from Indigo to the Insteon hub, so I'm sure I'll become very familiar with the process. 
I only want this as a transition away from Indigo and retire my Mac mini. I am moving soon, so I hope to get all the devices onto the Insteon Hub, use them until we move, and leave the Insteon gear in this house. In the next one I'm going all Z-Wave for switches/dimmers, I believe.
Thanks a lot for all your help! This is going to be a huge help! 
1 Like
You can add them all to the config.js file and they will all come in at once. I think someone said at one time that there was a limit to the number they were able to add at one time, but I don't remember what the amount was. There's no particular reason that there should be a limit. Try 10 at once maybe if all 40 at once doesn't work.
[Personal opinion] 
Z-Wave enthusiasts need not respond.
So much more trouble. Repeaters needed, signal issues, many don't have the nice features that Insteon device have, Z-Wave devices can often be slow, the mesh can get screwed up more easily by a bad device, etc. I have one Z-Wave switch, brand new, latest Z-Wave 500 series tech (not 700 series) for review. It's very nice, has really great features, but its response is slow. I don't have a huge Z-Wave mesh, but the repeating device on that Z-Wave mesh is S2 compatible. Currently it's on my older C-4 hub, so maybe when I get around to moving things to my C-7 hub it will be faster. Still, I much prefer the Insteon devices. Only limitation is that I cannot do smooth dimming of an Insteon device with a Pico. Not a huge deal. I really only have one Insteon dimmer I'm controlling with a Pico and I don't need to dim it often since it's my deck light, but a disadvantage of this integration all the same.
Sorry, I got locked out of the thread for 24 hours because my account is new and I had already replied quite a few times...
Since we last commented I have not had a pleasant experience trying to bridge Insteon and Hubitat to the point where I've given up on that approach and I'm using Indigo's HTTP API to send Get requests to turn lights on/off. There is no feedback (feedback was spotty using the web socket method anyway), but it's reliable and hasn't failed yet. Luckily I only need a few critical things pulled through for automation as I move away from Indigo, otherwise everything is accessed via Indigo's HomeKit bridge more often than not. I think I'll get everything set up on the Insteon hub, but wait until I move to completely retire Indigo.
On the subject of which vendor(s) to support, Insteon needs to market their product better. It's not that there's anything wrong with Insteon hardware, it's absolutely fantastic. It's that industry support for their hardware is poor, which may have something to do with the proprietary nature of their protocol. Only a handful of systems support it, and they're all very archaic compared to the more mainstream options. They're often very powerful in terms of flexibility and actual automation, but almost all of them lack modern features that make real automation possible (like native presence detection of some sort); those that don't have a very steep learning curve (I'm looking at you, HomeAssistant). I've been using Indigo for well over 10 years and while it's added new features, it still leaves me wanting more. Also, I was only using it to transition away from Indigo (and to leave behind for the next guy when I move), but Insteon's hub suuuuucks. Their products have been pretty static for a long time, and they're being left behind.
Just a footnote here, but I just added this to my C7 and refresh speed of devices that are manually controlled (e.g. At the switch) is near instant. The driver added my devices to the new hub just as expected and performance is amazing.
I'm manually migrating so I start with a clean database that doesn't have a history that goes back to version 1 of the platform. This is what I should have seen from the beginning when Chris wrote this driver. 2.2.4.x on the C7 offers such incredible performance gains. This is what Insteon on Hubitat should be. 
Yes. Did you trigger it once? It won’t have any state until you trigger it so it can send something for the listener app to forward to the websocket.
Yes
Can you see it detecting wet in the Insteon app?
[Edit] I think I see the issue. Go into your config.json file and take the decimals out of the Insteon ID. It shouldn't have them. Letters and numbers only. After fixing that, restart the server and listener, then delete the child device and recreate it.
If your other stuff is working with decimals in the Insteon Device IDs, that's strange, but they shouldn't be there either.
1 Like
That fixed it, thank you.
1 Like
Can someone please explain the architecture of this solution at a high level?
If an explanation of why a Node.js app is necessary already exists someplace, please point me to it.
Which statements below are correct and which are incorrect?
insteonserver.js
- Reads in config.json
- Listens for connections from client.js on websocket.Server({port: port#})
- Communicates with Insteon hub on port 25105
client.js
- Communicates with insteonserver.js at host = 'ws://127.0.0.1:port#
Insteon WS Parent Driver
- Communicates with the Insteon Hub on port 25105?
- Communicates with insteonserver.js at WebSocket IP Addr:Websocket Port (same at port# above?)
config.json
- What is the purpose of "server_port": "3500"
Server sends commands
Client listens for changes to update status
Parent app is how HE connects to the websocket. The reason the hub port is in there too is because we couldn’t do everything over the websocket alone, so @cwwilson08 came up with a brilliant hybrid solution.
Server port 3500 is for websocket. It can be changed if needed.
Out of curiosity, I connected an Insteon 2477D (your standard Insteon dimmer type) to a bank of four LED ceiling lights. These are what we installed during renovation with one, to two Hue Edison bulbs in the center as an accent light (Hue Bridge paired and Pico controlled). I am really enjoying this combination.
For the new owners, the LED ceiling lights will be Caséta dimmer controlled, but I found that the Insteon dimmer works equally well with these. No buzzing, ringing or flickering. Much better than the Caséta dimmers, since they store last dim level in hardware.
I may not go full RA2 after all. 
If a sensor's battery dies, will this app continue to modify the Last Update Time of the sensor's Device Details?
I don't think it can. But there might be something that updates it, which is not the actual sensor. I'm not able to even test that though, since my smart home mostly is pulled apart as I prepare to move.
New to Hubitat! Appreciate all the support already provided to the community @SmartHomePrimer and @cwwilson08
I'm having lots of trouble mostly with npm path and directory locations on my pi 3 (could be more to it that I am not seeing). Tried installing the latest node.js and the node_modules folder generated in /home/pi/ rather than /usr/local/lib/. This causes all the subsequent npm installs to fail and I haven't been able to piece things together after several attempts. I am coming from kuestess's smartthings solution and am familiar with the config file and device information. Haven't gotten that far in the installation to see child devices appear in Hubitat. Really appreciate any help getting this setup!
UPDATE
Solved some directory issues by moving files. Still stuck on step 12. Getting the following errors:
pi@raspberrypi:~ $ node insteonserver.js
undefined:23
]
^
SyntaxError: Unexpected token ] in JSON at position 565
at JSON.parse ()
at Object. (/home/pi/insteonserver.js:25:23)
at Module._compile (node:internal/modules/cjs/loader:1097:14)
at Object.Module._extensions..js (node:internal/modules/cjs/loader:1149:10)
at Module.load (node:internal/modules/cjs/loader:975:32)
at Function.Module._load (node:internal/modules/cjs/loader:822:12)
at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:77:12)
at node:internal/main/run_main_module:17:47
Node.js v17.4.0
It might not be compatible with the version of Node.js you're running. I run mine on an old Macbook Pro (not currently setup since my moving across the country) and because of that and other old node applications I'm running, I still use v6.10.2
I'm pretty sure @cwwilson08 had it running on a newer version of node, but this was so long ago that I doubt he tested anything after development stopped.
@SmartHomePrimer Thanks for the quick reply! I just had a chance to try reverting to v6.10.2 and I'm not sure I got much further. I might try imaging the rpi again just to start from scratch. Do you have any other ideas?
pi@raspberrypi:~ $ npm install -g n
changed 1 package, and audited 3 packages in 3s
found 0 vulnerabilities
pi@raspberrypi:~ $ n 6.10.2
installing : node-v6.10.2
mkdir : /home/pi/n/n/versions/node/6.10.2
fetch : https://nodejs.org/dist/v6.10.2/node-v6.10.2-linux-armv7l.tar.xz
installed : v6.10.2 (with npm 3.10.10)
pi@raspberrypi:~ $ node -v
v6.10.2
pi@raspberrypi:~ $ node insteonserver.js
undefined:23
]
^
SyntaxError: Unexpected token ] in JSON at position 565
at Object.parse (native)
at Object. (/home/pi/insteonserver.js:25:23)
at Module._compile (module.js:570:32)
at Object.Module._extensions..js (module.js:579:10)
at Module.load (module.js:487:32)
at tryModuleLoad (module.js:446:12)
at Function.Module._load (module.js:438:3)
at Module.runMain (module.js:604:10)
at run (bootstrap_node.js:393:7)
at startup (bootstrap_node.js:150:9)
