Can you explain the "seed" thanks
I tried using your driver, but found I could not log in after enabling 2FA, not sure what I did wrong.
Yeah...so might be the wrong term, but MFA seed, or MFA private, etc... When you setup an MFA token for sites, they usually provide a QR code to scan. Some apps that scan allow you to retrieve the "seed" or "secret" part of that. It is usually a base32 encoded text, similar to: I65VU7K5ZQL7WB4E
I use android and Aegis app allows you to view the secret for it. The server (Abdoe) and the client (app or this driver) both need to know what it is in order to generate the token. Also time needs to be in sync as it is time based as well. (Sorry for any confusion with the seed wording)
I also discovered that your driver won't install the child devices due to a namespace mismatch (it still refers to jorhett instead of x86cpu). I was able to fix it myself by modding the driver on line 140 and 141. Just an FYI
Ok, it appears that it's working by putting the "secret" code displayed at the time of enabling 2FA on abode web portal into the driver MFA Seed field. Thanks!
Am I correct that your driver should be able to automate logging back in if the websocket gets closed? Previously we had to add force it by creating an RM rule triggered off the isLoggedIn state becoming false.
I fixed the namespace, thank you! Rookie mistake.
For the MFA, yes... it should logout/login if needed, no RM needed. I've been logged in for over a month. It should also indicate in the Events that it did logout/in again too.
If the wording would be better as "secret" vs. "seed", I'm all for making it easier for people to understand.
1 Like
Thank you for picking up development of this driver!
1 Like
@x86cpu After a couple of days of testing I can say that your tweaks to this driver seem to be working very well for me.
That being said, I find the logging for the driver to be a bit excessive, any chance you'd consider adding the option to suppress the "info" logging along with "debug" logging that isn't controlled by driver option. I've "hacked" your code to remove the info logging, but I'm sure others would prefer a toggle?
I checked which log.info was there, and all that should not be very chatty at all. Basically notifying if prefs are saved, if mode is changed, and if the websocket connection is lost or reconnected. All of those should be a much rarer event. If you could let me know what you see more logging so (without debug/trace enabled).
I am aware of some "error" there, and still am still trying to track it down. My adjustment will do a callback URL when it sees a device update. It does this to try to detect what changed. The line 669 would imply that "device.update" is not for the Occupancy. Do you have the trace for the reply? I'm thinking the reply is null, which I can test for, but would need to know what contents it are. I do not have all devices to test with, so am missing some other device cases.
Thanks.
I prefer to reserve logging for "warn" and "error" events, I feel like it's much easier to spot problems. May just be me though 
I'll turn on trace logging to see if I can provide more info on the error. Thanks
Sure.... I can add a info switch login then as well. For that one it may not auto turn off, but can be a on or off manually.
1 Like
PM'd trace logging for the "out of bounds" error. Haven't been able to reproduce the line 669 error yet. I'm using 2 of the abode "multi-sensors" I'm suspect that this may be the culprit. Still trying to recreate.
Is there any chance you could add a state for "alarm activated/triggered"? I'd like to trigger a rule based on that if possible.
Can you please confirm you did not need to download any additional software to see the "secret" code? ie it was visible on the Abode web site when logged in?
Correct, it's shown as an alternative to the barcode when you configure 2FA on abode webUI
1 Like
Thanks. Will set aside some time this weekend to take the plunge. Would LOVE to be able to get rid of the roundabout process I'm using to trigger Hubitat actions on Abode motion sensor activities as described above at
I pushed a new version, added a Log info flag now (default enabled), so you can disable it and then leave it alone, it will not enabled/disable any timed method.
The plan is to try to trigger something for a device status when an Alarm goes off. I just need time to put the system in test mode and trigger some alarms to catch the events. I'd like to get so it can detect glass/smoke alarms too.
1 Like
I think this is working using RM to monitor the timeline, but I also haven't really taken the time to run thorough testing.
I cannot believe it, but I was able to:
- UnMatch in HPM
- Copy your Abode parent code and paste to replace what was there
- Install & save new drivers for the Door & Motion sensors
- In the new Abode parent drive, move the slider to "Create child devices", then hit Refresh and amazingly my door and most of my motion sensors showed up!!
I'll do a follow up post for the motion sensors that did not show up. Luckily, the one I want to use did show up, so now I'll play around with it.
Can you advise if these Abode device drivers work locally, like the HA integration claims it does, or if this is still cloud dependent?
SUCCESS!!!
THANK YOU so much for updating this driver / integration!!! This is absolutely awesome. Being able to use the Abode motion sensors as Hubitat triggers without a CUE automation triggering a smart plug in between (which is what I was doing) is AWESOME. Your driver is MUCH quicker.
My previous method had the motion sensor trigger a CUE event of turning an Abode Smart plug on and then off again in 1 minute. It was so slow that the motion would trigger the CUE event, which would trigger the Abode smart plug, which makes a "clicking" sound when turned on or off, and there was always a few seconds of delay after the smart plug clicking sound before the Hubitat event would trigger. Your driver is MUCH quicker.
THANK YOU!!
ETA: I also changed some door contact automations to use your driver. These are also faster with your driver than the previous timeline (without CUE automation) method. With your driver, the lag between opening a door and Hubitat triggering a light to go on or off is about 1 second. With the previous method of an Abode timeline entry being the trigger, the lag was about 2 seconds. So your method responds 2x as fast!
Yes, can confirm it works through RM monitoring the timeline. All you need is "contains Alarm"
1 Like
