As mentioned above it would be great to be able to also add the Verisure smartplugs and the Yale Doorman. I found that Home Assistant also have support for Verisure and have inlcuded locks and smartplugs. Maybe some of this code could be re-used for an easier implemantation? 
Hey Henrik,
I’ve used the Python code as a guide for what to do, but it’s still hard coding this without being able to test it. But if anyone wan’ts to add the code feel free to do a pull request on Github. Just make sure it’s tested and an option in the config.
Just wanted to add for anyone new coming into this: The Verisure API isn’t very reliable. Some times it fails 4 out of 5 times. So with polling each minute, it sometimes takes up to 5 minutes before the status of the alarm is updated.
I’ve though about what can be done to make this better, but there aren’t a lot of options. I’m being a bit cautious not to get hit by ST limits and throttling as well as bombing the Verisure servers.
Thanks Anders,
Unfortunately no programming skills to do it my self. But have the products so could help out to test any new code. I saw later that other people also mentioned the Home Assistant, sorry about that.
Yes, noticed that the API is not so reliable. If you just want the alarm status it is probably easier to use IFTT. For example together with Gmail, receive e-mail from Verisure with status “Armed” do actions in ST…
For making things happen with ST when the Verisure Alarm goes on I’m thinking about using one dedicated Verisure smartplug and in the Versiure plug put a z-wave plug. The Verisure plug is programmed to switch on when the alarm goes on witch will hopefully turn the z-wave plug on as well. Then use the z-wave plug to trigger other actions, turning on other lights, blinking lights red or similar.
1 Like
I have a Panasonic Heat Pump connected to Verisure as well. Is there a easy way to integrate this? Same thing with Yale Doorman?
1 Like
Hi. We won’t implement devices we don’t have ourselves for now. It’s not a matter of principle, but it is already quite time consuming to implement and test on the SmartThings platform. Implementing devices we don’t own and get that are tested through someone else, would take even longer. Sorry about that.
We’d welcome contributions though, so feel free to implement yourself.
Anders,
Have to learn some coding then! I eill try ig I get the hang of it 
New version available.
No big feature changes, but increased reliability. Switched over to using API, which gives far less errors. You should only rarely notice longer delay than one minute now. Verisure does sometimes respond with “Request limit reached”, and the app will now delay the next check for a couple of minutes.
Anders,
Hello,
Thanks for doing good work on this!
I’m seeing some errors in live logging, I’ve seen similar in the past with the previous version so I guess it is inevitable? Anyway I thought I should post them. With the previous version I got a lot of false positives due to Verisure status wasn’t seen properly in other smartthings processes probably due to latency, now it will be interesting to see if this changes to the better.
a618a7a1-2823-46ab-8c71-65360d3e44d1 10:12:00: error [verisure.checkPeriodically] Error updating alarm state java.net.SocketException: Connection reset
a618a7a1-2823-46ab-8c71-65360d3e44d1 10:12:00: debug getChildDevices(false), children=5
a618a7a1-2823-46ab-8c71-65360d3e44d1 10:12:00: debug [verisure.checkPeriodically] Periodic check from timer
a618a7a1-2823-46ab-8c71-65360d3e44d1 10:11:01: error [verisure.checkPeriodically] Error updating alarm state groovyx.net.http.HttpResponseException: Internal Server Error
a618a7a1-2823-46ab-8c71-65360d3e44d1 10:11:00: debug getChildDevices(false), children=5
a618a7a1-2823-46ab-8c71-65360d3e44d1 10:11:00: debug [verisure.checkPeriodically] Periodic check from timer
47b5c474-1663-4dcd-8218-8415249ceb20 10:10:57: debug Updating Controller State: level -> [100]
47b5c474-1663-4dcd-8218-8415249ceb20 10:10:57: debug getChildDevices(false), children=1
a97c3a38-229b-4caa-9ee2-e70c9daa5e16 10:10:57: debug Setting level to 100
a97c3a38-229b-4caa-9ee2-e70c9daa5e16 10:10:57: debug syncLevel(): [100]
47b5c474-1663-4dcd-8218-8415249ceb20 10:10:55: debug Device state change: sovrummet ambiance lamp 5 -> level = 100
47b5c474-1663-4dcd-8218-8415249ceb20 10:10:55: debug Updating Controller State: level -> [84]
47b5c474-1663-4dcd-8218-8415249ceb20 10:10:55: debug getChildDevices(false), children=1
a97c3a38-229b-4caa-9ee2-e70c9daa5e16 10:10:55: debug Setting level to 84
a97c3a38-229b-4caa-9ee2-e70c9daa5e16 10:10:55: debug syncLevel(): [84]
47b5c474-1663-4dcd-8218-8415249ceb20 10:10:53: debug Device state change: sovrummet ambiance lamp 5 -> level = 84
a618a7a1-2823-46ab-8c71-65360d3e44d1 10:10:00: error [verisure.checkPeriodically] Error updating alarm state groovy.lang.MissingPropertyException: No such property: type for class: groovy.util.slurpersupport.Node
a618a7a1-2823-46ab-8c71-65360d3e44d1 10:10:00: debug getChildDevices(false), children=5
a618a7a1-2823-46ab-8c71-65360d3e44d1 10:10:00: debug [verisure.checkPeriodically] Periodic check from timer
These are typical of versions older than 0.5.1. Which version do you use? Can you update to the newest one?
If you already updated, did you remember to publish? These errors shouldn’t happen in the new code.
Anders,
Found a couple of snags now, so update to the newest version.
Been getting XBN errors the last days. Did a quick (and a bit dirty) fix with the URL and pushed new code. Update.
Happy easter.
I’m getting those XBN errors now:
23:23:59: debug [verisure.handleLoginResponse] Response has error: {“errorGroup”:“SERVICE_UNAVAILABLE”,“errorCode”:“SYS_00004”,“errorMessage”:“XBN Database is not activated”}
Any more news on how to fix it?
and if you get blacklisted, how long does it usally take before it’s whitelisted again?
Sorry, it’s a TODO to use “both” servers. I think they actually switch over between the two when they go into production. Change the address of the server to: https://e-api01.verisure.com/xbn/2 (it says e-api02 in the existing code).
Thank you for quick respons. I got it to work with the other url. But now i get a new error:
09:53:20: error groovy.lang.MissingPropertyException: No such property: loggedBy for class: physicalgraph.device.cache.DeviceDTO @line 55 (parse)
Can’t really see something like this in my logs. Have you updated to the latest code? Does it repeat?
Yes, used original code. Evrything works now. Didnt get it anymore.
But i do get this:
17:58:16: debug [verisure.handleLoginResponse] Response has error: {“errorGroup”:“TOO_MANY_REQUESTS”,“errorCode”:“AUT_00021”,“errorMessage”:“Request limit has been reached”}
17:58:16: error [verisure.handleLoginResponse] Did not get correct response. Got response physicalgraph.scheduling.AsyncResponse@226ff571 .
It’s Verisures throttling, and nothing we can do anything about. Look at the other messages and it will tell you that it’s waiting X number of minutes before asking for a new update.
I’m getting error in line 404 and can’t figure out why:
java.lang.IllegalArgumentException: uri is required @line 404 (httpLog)
Anyone who can help?
Updated code on Github with automatic switching of Verisure servers when they change the URL. Update to the lates version.