Ok..... so different alarm types would be good then. I'd have to see more of which ones get triggered and how they show up in the timelines.
1 Like
Next time I'm home alone I'll test the alarm with all debugging active to see if I can provide the data
Encountered a unique issue. I added an Abode Device. After I paired the new device, I was not sure how to get it into Abode; perusing the discussion, I decided to enable debugging & trace logging. That got it into Abode, so I thought all was well.
Then I realized that several automations were not working; going into the apps, I found the Abode devices referenced to "Broken", so I reinserted all the Abode devices.
Unfortunately that did not fix it and I seem to have sort of a mess
- If I go to the Hubitat device page, there is one child device for each Abode device, as it should be, and that listing returns the proper data for "Last Activity". All the room names, which I'm fairly sure I assigned are gone, and no devices show status (so I have to go back in and select what I want it to show). The device event log does show the events, such as open/close on a door sensor. This tells me that when I enable debugging & trace logging, perhaps all devices "reimported" into HE and erased all the previous data for these two fields.
- If I go to the Hubitat log, there are two instance of each Abode child device listed at the top, but absolutely none of the trigger events show up. I'm fairly sure they used to show...
Then I realized one of my automations did not have Logging turned on. As soon as I turned on logging, an "Initialized" entry appeared on the log and the automation started to work again.
So the issue that remains is all devices are listed twice in the log header....(Hubitat, left side menu "Logs", Past Logs.) If I filter by device, There are two entries on the drop down by which I can filter, they have different device numbers (light blue text to the left) and it shows the devices were "installed" 13 seconds apart, at the time I enabled debugging & trace logging.
What did I do wrong and how do I fix it?
Possibly a reboot? I have not encountered that. I did add a new device when I added the multi sensor and pretty much did what you said. Should only need to save prefs to be enough for it to traverse the list of devices again. Each device it uses the RF id number from abode. So should always be unique and not able to create multiple devices.
I'm really not sure how to fix it. Hence a reboot suggestion if you are only seeing a single device for each in in the Abode habitat list.
---Eric
1 Like
Thanks for the quick reply - that got me on the right track.
I did a standard hub reboot, but that did not fix it.
In the reboot, advanced options, it offers the option to "Rebuild database on reboot." I presume there is no downside to that and that would be the way to fix it, so tried it, but it also did not solve it.
Then I did another reboot, this time selecting advanced options, and checking both the "Rebuild database on reboot" option and the option to clear the log.
Seems like clearing the log is what finally fixed it...
That sounds like a bug in hubitat, or corruption somewhere. Could be left over devices if you had them and had to delete a while back. I am not sure, but that does not sound like a normal scenerio that should have to be done unless something strnage happens.
Glad it's figured out.
1 Like
@x86cpu Just wanted to give an update, not necessarily drivers related totally. I was able to successfully pair a new First Alert SMC0410 ZWave CO/Smoke combo to Abode today, and after updating the package via HPM it showed up as a child device.
The SMC0410 is the successor to the discontinued First Alert ZCOMBO, and after some back and forth through the Abode Support Team I was able to pair it. Its currently only able to pair with Hubs that are running a Beta firmware that Abode will send out sometime soon, but I was able to get the Support Team to update my Hub to the Beta and paired the SMC0410 successfully.
1 Like
Are there any updates on adding support for Abode Cam2?
1 Like
No latest updates yet. Cam2 is still planned on being integrated. I just have had the lack of time due to moving and trying to sell our old house (market sucks). I still do plan on trying to integrate an "Alarm" switch and "Cam2" support.
2 Likes
In case it is helpful to others:
If, after you have this all set up, you need to either add or rename Abode devices in the Abode app, you can get that info into Hubitat. After you have added the device in Abode or changed the name:
- In Hubitat, in Devices, in the Abode Parent device, in the preferences tab, enable (move slider to the right) both Debug Logging and Trace Logging
- Click SAVE in the lower right of the preferences tab.
- Refresh/reload the device list page
Your added or revised device names should now be in Hubitat.
Hi guys
I want to get this alarm system but I have a religious issue that on Saturday I can't activate any lights or automation.
My current sensors have an rule that they don't work on Saturday and also there isn't any light on the sensor itself when it detects motion.
Do the abode alarms have a little light on it that turns on when motion is detected? If so is it easy to open and cut the led out?
Thanks
I use the Abode Iota hub and many of the abode sensors. The only devices I have which emitts light is their keypad and motion detector when it detects motion or to indicate a condition with the system and the hub itself when it is on, reporting a condition, and the alarm status. The FOB does when the button is pressed. The siren may also but I do not have one. The Hubs LEDs can be set to off manually but that control is not exposed to their CUE automation. I did find a way in CUE to define Shabbat though. The siren may also but I do not have it. Their devices seem to be sealed so I couldn't say how hard it is to disable the LED. I never tried Abode with any 3rd party sensors. It works with z-wave and zigbee smart plugs but does not expose any attributes beyond on/off. Perhaps their help desk can answer the question more precisely.
I have noticed that twice in the past month or so the Abode API has been up but the driver was not able to subscribe to the websocket. refresh, initialize, restart hub did nothing and it lasted about 1 hour before things started working again. So an issue on the Abode end. Just posting in case others have seen it? I only notice because certain rules triggering lights stopped working.
Also, in trying to diagnose this I noticed that the normal logging level does not include logging the opening and closing of doors, etc. I prefer to have my logging levels more verbose on the normal logging level as I forward everything to a syslog server and it is useful for diagnosing things like this. I added that into my local copy but didn't know if this was something to be considered for the broader implementation?
Hi
Thanks so much for your detailed reply, I spoken to Abode but the sales staff didn't seem to know exactly what lights came on and how it worked.
Basicly the rest of the system having lights isn't a problem, it's just me triggering them by movement or open/closing a door is what isn't allowed.
So if the motion sensors have a light on them that flash even when the alarm is unset then I won't be able to use them unless there's some work around such as removing the actual light or I'd have to cover the sensors every Friday which isnt practical.
Any other wireless alarms you guys could recommend that I will allow me to use the same sensors to trigger lights going on and off with hubitat?
Thanks
The contact sensors do not have any leds. But they do emit energy in a not visible portion of the electro magnetic spectrum. The motion sensor does emit in the visible and not visible. If the system mode is changed, a status led changes on the hub.
Apparently unrelated to my previous issue I recently noticed that WebSocket events have stopped flowing. After investigating, I found the connection drops at exactly 85 seconds every time — which is the sum of Abode's pingInterval (25s) + pingTimeout (60s).
It appears Abode's Socket.IO server now expects EIO=4 protocol (client sends pings) rather than EIO=3 (server sends pings). The driver connects with ?EIO=3, so neither side initiates pings, and the server disconnects after 85s. @x86cpu can I confirm that I am on the right track here?
In testing I found that
?EIO=3— connection drops at exactly 85s, every time?EIO=4— connection stays alive indefinitely with client-initiated pings getting pong responses
I tested on my local copy but have so far been unable to get a sustained ping to go out. All scheduling methods (runIn, schedule, runEvery*) for a WebSocket keepalive ping register without error but never fire — also a stuck Quartz trigger persists through reboots and unschedule(). But I don't have much experience with this so it could be I am just on the wrong track.
Is anyone else seeing Abode events that stop working, or connections dropping? The driver does auto-reconnect every 5 minutes via checkSocketTimeout, so you might not notice unless you're watching the logs closely — it would just look like periodic reconnects.
I will take a look, so far it's been working for me as-is.
So it seems:
EIO=4 (Socket.IO v4): Default for Socket.IO v4. Requires the client to send the CONNECT message packet (40).
EIO=3 (Socket.IO v2/v3): Used in older versions. If a v4 server receives this, it may require the allowEIO3: true option for compatibility.
I am testing changing to EIO=4 with my home Abode.
Ok.. Going back to EIO=3, mainly as:
EIO=3 (Socket.IO v2.x) 
Initiator: The client sends the Ping.
Response: The server responds with a Pong.
Packet IDs: Ping is 2, and Pong is 3.
EIO=4 (Socket.IO v3.x and v4.x) 
Initiator: The server sends the Ping.
Response: The client responds with a Pong.
I keep seeing server side send a Pong, not a Ping, which is EIO=3 The code should send a Pong to a Ping, or a Ping to a Pong, whatever server side sends. However only seeing server side sending Pong, impllies the EIO=3 use.
