Testers for Verisure openHAB 2 binding

Hi @msv12

Is it possible to get status from Door/Windows as item type Contact?

Is it possible to get a channel in Doorlock for Autolock ON/OFF?

/Mike

Just installed your build and looks like it works great. Thanks!
I have a VeriSure alarm system with Door/window contacts, Photo detectors, Motion detectors, and Smoke detectors. They seem to work fine (did some initial testing).
Just wanted to report on my results with this build, since you don’t have all the VeriSure equipment at home… ;o)

I’ve just added this binding and it works as intended. Thanks for good work.

To get around the API rate limit, is there maybe another way to integrate with Verisure the through My Verisure website? I have found a Python-based project, which seems to integrate via the API used by the Verisure native mobile apps: https://github.com/persandstrom/python-verisure - Not sure if the rate limit applies to this way of accessing the Verisure system.

Tested working good
(but if i lock the door from the app it wont refresh in openhab before 30minutes, is that correct)?
Switch item=Dor_lock
Text item=Dor_Status
Text item=Dor_whois Text item=Dor_LastTime
Text item=Dor_LastTime
Switch Dor_lock “Hoveddør” {channel=“verisure:lock:1:thingID:doorlock”}
String Dor_Status “Status” {channel=“verisure:lock:1:thingID:status”}
String Dor_whois “ID” {channel=“verisure:lock:1:thingID:changername”}
String Dor_LastTime “Siste” {channel=“verisure:lock:1:thingID:timestamp”}

I get the “Verisure Binding” thing to work, and it states “online”. I have a Yaleman Lock. When I search for new things, it reports that the lock (“MainDoor”) was found and should be in the inbox, however it never appears in the in-box. When I try to manually add a lock with the name “MainDoor” it never initialize, it says “UNINITIALIZED - HANDLER_INITIALIZING_ERROR”

Any one that has any idea why it does not work?

Any news of this binding?

/Mike

I’ve made a re-design of the Verisure binding to support multiple installations/sites since I also have a Verisure installation at my summer house.

I’ve based the re-design on the work made by @Andreas_L, @jarlebh and @msv12 but updated it to handle multiple sites, the changes are not backward compatible so all discovered things will get new internal IDs.

I’ve also added support for some new things:

  • Bridge
  • Alarm
  • Smoke Detector (climate)
  • Water Detector (climate)
  • Siren (climate)
  • Night Control
  • Yaleman SmartLock
  • SmartPlug
  • Door/Window Status
  • User Presence Status
  • Broadband Connection Status

The source code can be found here in the 4788-verisure branch and the README can be found here.
I’ve also compiled a jar-file based on OH2.5 but it also works for OH2.4.

openhab@openhab2:/usr/share/openhab2/addons $ md5sum org.openhab.binding.verisure-2.5.0-SNAPSHOT.jar 
c6eb6f26219a306455916b5fb1ff9153  org.openhab.binding.verisure-2.5.0-SNAPSHOT.jar

The updated binding has been initially tested by @tnemrap and I’ve also got great idéas from Mike in improving the binding functionality.

NOTE: During code review by the maintainers I’ve done some breaking changes to the original jar-file that was referenced in this post. Please read the updated README for changes, the biggest change is that I’ve implemented a configuration property for each Thing called deviceId, hence if you have defined things manually in a things file, you will need to update that according to the updated README.

NOTE: The default refresh period is still 10 minutes, be aware that Verisure might detect if you poll to often!

Happy testing! :slight_smile:

BR,

/Janne

2 Likes

Seems to be an issue with adding Yale Smartlocks with the new binding

Status: UNINITIALIZED - HANDLER_INITIALIZING_ERROR org.openhab.binding.verisure.internal.VerisureAlarmJSON cannot be cast to org.openhab.binding.verisure.internal.VerisureSmartLockJSON

I get this issue using the following setting in my things-file and then allowing GUI-discovery of the SmartLock

Bridge verisure:bridge:1 "Versiure Bridge" [ username=<redacted>, password=<redacted>, refresh=300, numberOfInstallations="1"]

Are you using Jannes Binding?
This works for me

Bridge verisure:bridge:1 "Verisure Bridge" [username="email@email.xx", password="secret", pin="123456",  numberOfInstallations="1"]{
    Thing alarm alarm_1 "Verisure Alarm"  [ ID="alarm_1" ]    
    Thing smartLock 2A8L_XXXX "Entré Lås"  [ ID="2A8L_XXXX" ]    
    Thing doorWindowSensor 2JJS_XXXX "Entré Dörr" [ ID="2JJS_XXXX" ]
    Thing doorWindowSensor 2JJG_XXXX "Altandörr sovrum" [ ID="2JJG_XXXX" ]
    Thing doorWindowSensor 2JJS_XXXX "Källardörr" [ ID="2JJS_XXXX" ]
    Thing doorWindowSensor 2JJS_XXXX "Altandörr kök" [ ID="2JJS_XXXX" ]
    Thing smokeDetector 2AJ2_XXXX  "Hall Rökdetektor" [ ID="2AJ2_XXXX" ]
    Thing smokeDetector 2AJ2_XXXX  "Gillestuga Rökdetektor" [ ID="2AJ2_XXXX" ]
}

/Mike

This does not work for me, giving the same response:

 Bridge verisure:bridge:1 "Versiure Bridge" [ username=<redacted>, password=<redacted>, refresh=300, 
 numberOfInstallations="1"] {
 	Thing smartLock 2AQSxxxx "Verisure Entrance Yale Doorman"  [ ID="2AQSxxxx" ]    
 }

I do have a different ID code pattern. Perhaps it is a different version of Yale Doorman that causes an issue?

You should have the pin in Bridge.
Don’t you have a _ sign in your ID’s?

/Mike

The ID is indeed lacking an underscore.

As for the pin, is it required if I only wish to read the status of the lock, but not alter it?

Have you tried with pin and underscore?

/Mike

No help. Instead of generating a type error it is now just stuck in Initializing.

Note that the OpenHAB discovery service finds the lock without the underscore, and identifies it as a smartLock


ID: 2AQSxxxx, Location: Huvudentré UNINITIALIZED - HANDLER_INITIALIZING_ERROR
Yale Doorman SmartLock
verisure:smartLock:1:2AQSxxxx

Edit - stack trace:

2019-01-22 00:01:58.645 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.initialize()' on 'org.openhab.binding.verisure.handler.VerisureThingHandler@17bb773': org.openhab.binding.verisure.internal.VerisureAlarmJSON cannot be cast to org.openhab.binding.verisure.internal.VerisureSmartLockJSON

java.lang.ClassCastException: org.openhab.binding.verisure.internal.VerisureAlarmJSON cannot be cast to org.openhab.binding.verisure.internal.VerisureSmartLockJSON
	at org.openhab.binding.verisure.handler.VerisureThingHandler.update(VerisureThingHandler.java:387) ~[?:?]
	at org.openhab.binding.verisure.handler.VerisureThingHandler.bridgeStatusChanged(VerisureThingHandler.java:348) ~[?:?]
	at org.openhab.binding.verisure.handler.VerisureThingHandler.initialize(VerisureThingHandler.java:318) ~[?:?]
	at sun.reflect.GeneratedMethodAccessor56.invoke(Unknown Source) ~[?:?]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
	at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
	at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:153) [102:org.eclipse.smarthome.core:0.10.0.oh240]
	at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:53) [102:org.eclipse.smarthome.core:0.10.0.oh240]
	at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
	at java.lang.Thread.run(Thread.java:748) [?:?]

Commit used for the build: a5a989fdbdc7ea3c7a179024c7f0cc7bd6362de3
Also tried with the precompiled version above - no dice there either.

Interesting, are you testing in an IDE or in a production system?

Commit used for the build: a5a989fdbdc7ea3c7a179024c7f0cc7bd6362de3

That is correct commit.

The ID for the Yale Doorman Smartlock does not contain an _ as you’ve noted, but all other IDs for Verisure things does, hence to generate similar IDs when using auto detetction I decided to add an _ to have a uniform ID for all detected things (that has an ID visible in Verisure homepage).’
Hence it is necessary to add an _ if you define the smartLock in a things-file.

Since I use auto detection for all things, I’ve not tested to actually define things in a things-file before, just the Bridge. However, Mike has done that and I’ve now tested in my IDE and it works fine, so something must be fooling us.

I’ve tested both with and without pin, and it works to see status for both configurations, example of my verisure.things file without specifying pin:

Bridge verisure:bridge:1 "Versiure Bridge" [ username="test@gmail.com", password="mysecret", refresh="300", numberOfInstallations="2"] {
 	Thing smartLock 2XYZ_8XYZ "Verisure Entrance Yale Doorman"  [ ID="2XYZ_8XYZ" ]    
 }

Running in the IDE both Bridge and thing gets online, and when I link channel in Paper UI, I see the values populated under Control.

If you test in an IDE, could you try to remove the folder:
Your path/openhab2-master/git/openhab-distro/launch/home/userdata

so that we make sure to start clean, and then only define the bridge in the verisure.things file:

Bridge verisure:bridge:1 "Versiure Bridge" [ username="test@gmail.com", password="mysecret", refresh="300", numberOfInstallations="1"]

The make sure that the Bridge comes online and then let auto discovery find all the Verisure things.

If you run in a production system, I would like to see what the following command sequence using the Karaf console gives:

openhab@openhab2:~ $ openhab-cli console

Logging in as openhab

                          __  _____    ____      
  ____  ____  ___  ____  / / / /   |  / __ )     
 / __ \/ __ \/ _ \/ __ \/ /_/ / /| | / __  | 
/ /_/ / /_/ /  __/ / / / __  / ___ |/ /_/ /      
\____/ .___/\___/_/ /_/_/ /_/_/  |_/_____/     
    /_/                        2.4.0
                               Release Build   

Hit '<tab>' for a list of available commands
and '[cmd] --help' for help on a specific command.
Hit '<ctrl-d>' or type 'system:shutdown' or 'logout' to shutdown openHAB.

openhab> bundle:list -s |grep verisure                                                                                                                                                                      
259 │ Active   │  80 │ 2.5.0.201901131614     │ org.openhab.binding.verisure

If this shows more that one bundle installed, then that old bundle must be stopped and uninstalled.
Use Karaf console and the ID and the following commands to stop and uninstall:

openhab> bundle:stop 257
openhab> bundle:uninstall 257

if the ID is 257 for the old binding that should be uninstalled.
Note that the version of the listed binding, it shall be 2.5.0.201901131614.

If you want to restart the binding in the production environment to make sure you run the correct jar-file, you can also do that using Karaf console. If I would to do it with my example above with ID 259 I would use the following commands:

openhab> bundle:stop 259
openhab> bundle:uninstall 259
openhab> bundle:install -s file:/usr/share/openhab2/addons/org.openhab.binding.verisure-2.5.0-SNAPSHOT.jar
Bundle ID: 263
openhab> bundle:list -s |grep verisure
263 │ Active   │  80 │ 2.5.0.201901131614     │ org.openhab.binding.verisure

The log (with log level DEBUG) will then contain (NOTE: Since I have 2 instances, your log will be slightly deifferent):

2019-01-22 20:42:22.641 [DEBUG] [risure.handler.VerisureBridgeHandler] - Stop immediate refresh for job java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@f61f78
2019-01-22 20:42:22.644 [DEBUG] [ng.verisure.internal.VerisureSession] - Should dispose allocated stuff here in session
2019-01-22 20:42:22.659 [DEBUG] [sure.internal.VerisureHandlerFactory] - unsetHttpClientFactory this: org.openhab.binding.verisure.internal.VerisureHandlerFactory@13d24cf
2019-01-22 20:42:22.668 [DEBUG] [org.openhab.binding.verisure        ] - ServiceEvent UNREGISTERING - {org.eclipse.smarthome.core.thing.binding.ThingHandlerFactory}={service.id=446, service.bundleid=259, 
service.scope=bundle, component.name=org.openhab.binding.verisure.internal.VerisureHandlerFactory, component.id=270} - org.openhab.binding.verisure
2019-01-22 20:42:22.719 [DEBUG] [org.openhab.binding.verisure        ] - BundleEvent STOPPING - org.openhab.binding.verisure
2019-01-22 20:42:22.741 [DEBUG] [org.openhab.binding.verisure        ] - ServiceEvent UNREGISTERING - {org.eclipse.smarthome.config.discovery.DiscoveryService}={service.id=447, service.bundleid=259, servi
ce.scope=singleton} - org.openhab.binding.verisure
2019-01-22 20:42:22.748 [DEBUG] [org.openhab.binding.verisure        ] - BundleEvent STOPPED - org.openhab.binding.verisure
2019-01-22 20:42:33.664 [DEBUG] [org.openhab.binding.verisure        ] - BundleEvent UNRESOLVED - org.openhab.binding.verisure
2019-01-22 20:42:34.699 [DEBUG] [org.openhab.binding.verisure        ] - BundleEvent UNINSTALLED - org.openhab.binding.verisure
2019-01-22 20:42:50.569 [DEBUG] [org.openhab.binding.verisure        ] - BundleEvent INSTALLED - org.openhab.binding.verisure
2019-01-22 20:42:50.888 [DEBUG] [org.openhab.binding.verisure        ] - BundleEvent RESOLVED - org.openhab.binding.verisure
2019-01-22 20:42:50.894 [DEBUG] [org.openhab.binding.verisure        ] - BundleEvent STARTING - org.openhab.binding.verisure
2019-01-22 20:42:51.062 [DEBUG] [sure.internal.VerisureHandlerFactory] - setHttpClientFactory this: org.openhab.binding.verisure.internal.VerisureHandlerFactory@10e498c
2019-01-22 20:42:51.092 [DEBUG] [org.openhab.binding.verisure        ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.core.thing.binding.ThingHandlerFactory}={service.id=461, service.bundleid=263, ser
vice.scope=bundle, component.name=org.openhab.binding.verisure.internal.VerisureHandlerFactory, component.id=275} - org.openhab.binding.verisure
2019-01-22 20:42:51.094 [DEBUG] [org.openhab.binding.verisure        ] - BundleEvent STARTED - org.openhab.binding.verisure
2019-01-22 20:42:51.419 [DEBUG] [sure.internal.VerisureHandlerFactory] - createHandler this: org.eclipse.smarthome.core.thing.internal.BridgeImpl@9dd770e5
2019-01-22 20:42:51.423 [DEBUG] [sure.internal.VerisureHandlerFactory] - Create VerisureBridgeHandler
2019-01-22 20:42:51.529 [DEBUG] [org.openhab.binding.verisure        ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.config.discovery.DiscoveryService}={service.id=462, service.bundleid=263, service.
scope=singleton} - org.openhab.binding.verisure
2019-01-22 20:42:51.591 [DEBUG] [risure.handler.VerisureBridgeHandler] - Initializing Verisure Binding
2019-01-22 20:42:51.599 [DEBUG] [ng.verisure.internal.VerisureSession] - VerisureSession:initialize
2019-01-22 20:42:51.601 [DEBUG] [ng.verisure.internal.VerisureSession] - Attempting to log in to mypages.verisure.com
2019-01-22 20:42:52.509 [DEBUG] [ng.verisure.internal.VerisureSession] - HTTP Response (200) Body:{"status":"ok","redirectUrl":"/","message":null}
2019-01-22 20:42:52.510 [DEBUG] [ng.verisure.internal.VerisureSession] - Login URL: https://mypages.verisure.com/j_spring_security_check?locale=en_GB
2019-01-22 20:42:52.511 [DEBUG] [ng.verisure.internal.VerisureSession] - Login result: {}{"status":"ok","redirectUrl":"/","message":null}
2019-01-22 20:42:52.512 [DEBUG] [ng.verisure.internal.VerisureSession] - VerisureSession:handleInstallations
2019-01-22 20:42:52.513 [DEBUG] [ng.verisure.internal.VerisureSession] - Attempting to configure installation instance
2019-01-22 20:42:52.514 [DEBUG] [ng.verisure.internal.VerisureSession] - Start URL: https://mypages.verisure.com/uk/start.html?inst=1
2019-01-22 20:42:53.745 [DEBUG] [ng.verisure.internal.VerisureSession] - Got CSRF: 7826379bb2d21b34cc49ccff794c72bf9b358621d1686473c73161d4d8a1002e
2019-01-22 20:42:53.910 [DEBUG] [ng.verisure.internal.VerisureSession] - Attempting to configure installation instance
2019-01-22 20:42:53.911 [DEBUG] [ng.verisure.internal.VerisureSession] - Start URL: https://mypages.verisure.com/uk/start.html?inst=2
2019-01-22 20:42:54.476 [DEBUG] [ng.verisure.internal.VerisureSession] - Got CSRF: 7826379bb2d21b34cc49ccff794c72bf9b358621d1686473c73161d4d8a1002e
2019-01-22 20:42:54.525 [DEBUG] [risure.handler.VerisureBridgeHandler] - Start automatic refresh null
2019-01-22 20:42:54.528 [DEBUG] [risure.handler.VerisureBridgeHandler] - Scheduling at fixed delay refreshjob java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@100e04c
2019-01-22 20:43:04.528 [DEBUG] [risure.handler.VerisureBridgeHandler] - VerisureBridgeHandler - Polling thread is up'n running!
2019-01-22 20:43:06.538 [DEBUG] [ng.verisure.internal.VerisureSession] - Attempting to log in to mypages.verisure.com
2019-01-22 20:43:07.129 [DEBUG] [ng.verisure.internal.VerisureSession] - HTTP Response (200) Body:{"status":"ok","redirectUrl":"/","message":null}
2019-01-22 20:43:07.131 [DEBUG] [ng.verisure.internal.VerisureSession] - Login URL: https://mypages.verisure.com/j_spring_security_check?locale=en_GB
2019-01-22 20:43:07.133 [DEBUG] [ng.verisure.internal.VerisureSession] - Login result: {}{"status":"ok","redirectUrl":"/","message":null}
2019-01-22 20:43:07.134 [DEBUG] [ng.verisure.internal.VerisureSession] - areWeLoggedIn() - Checking if we are logged in
2019-01-22 20:43:07.405 [DEBUG] [ng.verisure.internal.VerisureSession] - HTTP HEAD response: 
2019-01-22 20:43:07.406 [DEBUG] [ng.verisure.internal.VerisureSession] - Status code 200. Probably logged in
2019-01-22 20:43:07.817 [DEBUG] [ng.verisure.internal.VerisureSession] - Page type: start-page no-js
2019-01-22 20:43:07.820 [DEBUG] [ng.verisure.internal.VerisureSession] - VerisureSession:updateStatus
2019-01-22 20:43:07.820 [DEBUG] [ng.verisure.internal.VerisureSession] - Attempting to configure installation instance
2019-01-22 20:43:07.822 [DEBUG] [ng.verisure.internal.VerisureSession] - Start URL: https://mypages.verisure.com/uk/start.html?inst=1
2019-01-22 20:43:08.177 [DEBUG] [ng.verisure.internal.VerisureSession] - Got CSRF: 5b79193176d71122b624f99ef1b91bb04526536a585300e2aecfae5e17d79909
2019-01-22 20:43:08.186 [DEBUG] [ng.verisure.internal.VerisureSession] - HTTP GET: https://mypages.verisure.com/remotecontrol

The last row contains the URL used for quering the Alarm and SmartLock status, if you still have problems it would be great if you could log into Verisures webpage with your credentials, and the paste:

https://mypages.verisure.com/remotecontrol

in your web browser. You should then see a JSON containing two objects:

[
{
date: "Idag 19:26",
disarmed: true,
notAllowedReason: "",
image: "locked",
operational: true,
changeAllowed: true,
label: "Låst",
type: "DOOR_LOCK",
name: "",
location: "Ytterdörr",
id: "2XYZ8XYZ",
secureMode: false,
status: "locked"
},
{
date: "Igår 08:40",
notAllowedReason: "",
name: "John Doe",
changeAllowed: true,
id: 1,
label: "Avlarmat",
type: "ARM_STATE",
status: "unarmed"
}

The Verisure binding uses the first object for SmartLock and the second for Alarm things status.

That was a long post, bear with me, but I am eager to find out what the root-cause for your problem is. :slight_smile:

BR,

/Janne

1 Like

OK, here goes. My setup and testing are both done in a production system.

First I tried to uninstall all old bundles (I had one renamed to org.openhab.binding.verisure-2.5.0-SNAPSHOT.jar.bak which I thought would be enough to remove the binding - it was not).
The bundle I am using now is the one downloaded from the original post above.

252 ¦ Active   ¦  80 ¦ 2.5.0.201901151930     ¦ org.openhab.binding.verisure

The error remains.

Second, I added debugging info for that binding and got the following HTTP-response (confirmed this in my browser as well).

2019-01-22 23:48:15.959 [DEBUG] [ng.verisure.internal.VerisureSession] - HTTP GET: https://mypages.verisure.com/remotecontrol

2019-01-22 23:48:16.028 [DEBUG] [ng.verisure.internal.VerisureSession] - HTTP Response (200) Body:
[{
"date":"19/01/19 15:21",
"disarmed":false,
"notAllowedReason":"",
"image":"locked",
"operational":true,
"changeAllowed":true,
"label":"Locked",
"type":"DOOR_LOCK",
"name":"",
"location":"Huvudentré",
"id":"2AQSxxxx",
"secureMode":false,
"status":"locked"
},{
"date":"Today 16:05",
"disarmed":false,
"notAllowedReason":"",
"image":"locked",
"operational":true,
"changeAllowed":true,
"label":"Locked",
"type":"DOOR_LOCK",
"name":"",
"location":"Sidoentré",
"id":"2AXDxxxx",
"secureMode":false,
"status":"locked"
}]

These are correctly my two locks (connected via a “Microenhet”). I don’t have an actual alarm connected to this setup.

Oh, and I am using only discovery from now on. Skipping the definitions of anything except the bridge in the things-files.

Thanks for the info! :slight_smile:
This is a setup that I’ve not tested, the new design assumes you have an alarm.

I need to look into this and it will be hard for me to test since I only have one SmartLock and also an alarm.
Is it possible that you can test new jar-builds for me?

I will look into this use-case during the week-end.

BR,

/Janne

I can be a guinea pig :slight_smile: no worries.

Robin

I cannot reproduce the problem in my IDE :frowning: , I’ve used the JSON posted above with 2 SmartLocks and no alarm and simulated your environment.
I’ve sent you a PM asking for JSONs for the following queries:

https://mypages.verisure.com/overview/climatedevice
https://mypages.verisure.com/settings/smartplug
https://mypages.verisure.com/settings/doorwindow
https://mypages.verisure.com/overview/doorlock/2AQSxxxx use your real ID)
https://mypages.verisure.com/overview/doorlock/2AXDxxxx (use your real ID)
https://mypages.verisure.com/overview/usertrackingcontacts
https://mypages.verisure.com/overview/ethernetstatus

BR,

/Janne

Hi, regarding the refresh/polling of 10 minutes. I took a very quick look at the decompiled Android app, and it is certainly using Google Cloud Messaging (retired and being replaced by Firebase Cloud Messaging this spring). Have you tried to write a small client registering at GCM for push messages?

Regards, Arne