@jannegpriv Hi, tested the new version. Great work!
I tested the smart lock (as it is the only item I have connected to the verisure system), and noticed that you use separate channels for reading (status) and writing (commands).
Wouldn’t it be simpler if they were merged to the same channel with both reading and writing support?
Arne
Wouldn’t it be simpler if they were merged to the same channel with both reading and writing support?
Do you mean that the non-set channel types (smartLockStatus/autoRelockEnabled ) should be removed?
No, merged. IMHO
smartLockStatus should return the current status (mapped to ON/OFF instead of returning Locked/Unlocked) when you receive a RefreshType (of command) and do actual unlocking/locking when you receive OnOffType (of command).
Same for the auto relocking feature - although I would call the channel just autoRelock and make it behave as above.
I think I saw 2 other sets of channels that I personally would merge in the smartLock thing setup, but here might be other similar cases in the other Thing channels.
Cheers
Maybe we even should abandon repeating the word “smartLock” in the channel names? They are linked to the Thing anyways.
Maybe smartLockStatus should even be renamed to deadbolt?
Or maybe I am just nitpicking ?
smartLockStatusshould return the current status (mapped to ON/OFF instead of returning Locked/Unlocked) when you receive aRefreshType(of command) and do actual unlocking/locking when you receiveOnOffType(of command).
I’m not sure what you mean when you write that the channel should return status, all status channels are updated via the polling thread that in turn calls the Verisure API, this is done each refresh timeout.
This cannot be done too often as Verisure then might complain, I’ve used a refresh time of 10 minutes without getting any complaints.
Therefor I don’t think it would be feasable to update the status more often than the binding does today.
You can already with current implementation check the ON/OFF status of the smartLock using the status of the Switch, all set-channels will also generate a so called immediate refresh to update status directly (all status channels will then be updated as a bonus).
There is also a possibility to update the status of all status channels by sending a RefreshType command to the status channel of the bridge, however it is not recommended use this too often as mentioned earlier.
I am not saying anything about update interval nor polling.
You can already with current implementation check the ON/OFF status of the smartLock using the status of the Switch
OK, so If I understand you correctly you have implemented it as I suggest except that the smartLockStatus channel is redundant?
Great binding, many thanks! I have some trouble getting rules properly triggered by changes on the numericStatus/alarmStatus channels. Items:
Number Home_GrindNumeriskStatus “Status [MAP(se.map):%s]” (Home_Grind) {channel=“verisure:alarm:xyz:alarm_1:numericStatus”}
String Home_Grindstatus “Grindstatus [%s]” (Home_Grind) {channel=“verisure:alarm:xyz:alarm_1:alarmStatus”}
I have set up an IFTTT account that tracks push messages from Verisure and then changes an Openhab Item, which in turn triggers a rule that fires a bridge Refresh so that the alarm status is refreshed in ‘real time’ (well, within a minute or so).
Sample rules:
rule “Alarm activated”
when
Item Home_GrindNumeriskStatus changed to 2
then
…
FF_Dimmer.sendCommand(DIM_OFF)
end
rule “Alarm Home activated”
when
Item Home_GrindNumeriskStatus changed to 1
then
logInfo(…)
end
The latter seems to work, after some time a message is added to the log. The former, on the other hand, seems not to work. It’s a bit tricky and time-consuming to test, rewrite and re-test the former rule, since obviously I can’t be at home when the alarm is set to 2, but the dimmer is still on when I return home and disarm the alarm.
I have planned to test the alarmStatus channel instead:
rule “Alarm activated”
when
Item Home_Grindstatus changed to “Armed Away”
then
…
FF_Dimmer.sendCommand(DIM_OFF)
end
rule “Alarm Home activated”
when
Item Home_Grindstatus changed to “Armed Home”
then
…
end
I’m however a bit unsure if it should be “Armed Away”, “ARMED AWAY”, ARMED_AWAY (constant) or something else?
Could it be the use of transformation that causes issues here?
Great binding!
However since approximately yesterday I get “Communication Error” for the bridge thing and the following log indicating error. Any idea? Related to new Verisure web? Prior to yesterday it has worked like a charm for a long time
2019-05-03 19:46:07.863 [DEBUG] [ng.verisure.internal.VerisureSession] - Login URL: https://mypages.verisure.com/j_spring_security_check?locale=en_GB
2019-05-03 19:46:07.864 [DEBUG] [ng.verisure.internal.VerisureSession] - sendHTTPpost URL: https://mypages.verisure.com/j_spring_security_check?locale=en_GB Data:j_username=xxx.xxx@xxx.cc&j_password=xxxxxx&spring-security-redirect=/uk/start.html
2019-05-03 19:46:07.865 [DEBUG] [ng.verisure.internal.VerisureSession] - HTTP POST Request HttpRequest[POST /j_spring_security_check HTTP/1.1]@607b1733.
2019-05-03 19:46:08.315 [DEBUG] [ng.verisure.internal.VerisureSession] - HTTP Response (200) Body:{"status":"ok","redirectUrl":"/uk/start.html","message":null}
2019-05-03 19:46:08.316 [DEBUG] [ng.verisure.internal.VerisureSession] - Login result: {}{"status":"ok","redirectUrl":"/uk/start.html","message":null}
2019-05-03 19:46:08.316 [DEBUG] [ng.verisure.internal.VerisureSession] - VerisureSession:handleInstallations
2019-05-03 19:46:08.316 [DEBUG] [ng.verisure.internal.VerisureSession] - Attempting to configure installation instance
2019-05-03 19:46:08.316 [DEBUG] [ng.verisure.internal.VerisureSession] - Start URL: https://mypages.verisure.com/uk/start.html?inst=1
2019-05-03 19:46:08.447 [WARN ] [ternal.handler.VerisureBridgeHandler] - Failed to initialize! Exception caught: null
java.lang.NullPointerException: null
at org.openhab.binding.verisure.internal.VerisureSession.getCsrfToken(VerisureSession.java:260) ~[268:org.openhab.binding.verisure:2.5.0.201904261733]
at org.openhab.binding.verisure.internal.VerisureSession.configureInstallationInstance(VerisureSession.java:243) ~[268:org.openhab.binding.verisure:2.5.0.201904261733]
at org.openhab.binding.verisure.internal.VerisureSession.getInstallations(VerisureSession.java:290) ~[268:org.openhab.binding.verisure:2.5.0.201904261733]
at org.openhab.binding.verisure.internal.VerisureSession.initialize(VerisureSession.java:118) ~[268:org.openhab.binding.verisure:2.5.0.201904261733]
at org.openhab.binding.verisure.internal.handler.VerisureBridgeHandler.initialize(VerisureBridgeHandler.java:129) [268:org.openhab.binding.verisure:2.5.0.201904261733]
at sun.reflect.GeneratedMethodAccessor72.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) [?:?]
2019-05-03 19:46:08.451 [DEBUG] [sure.internal.VerisureHandlerFactory] - createHandler this: org.eclipse.smarthome.core.thing.internal.ThingImpl@9d19fb06
2019-05-03 19:46:08.451 [DEBUG] [sure.internal.VerisureHandlerFactory] - createHandler this: org.eclipse.smarthome.core.thing.internal.ThingImpl@3690c120
2019-05-03 19:46:08.451 [DEBUG] [sure.internal.VerisureHandlerFactory] - createHandler this: org.eclipse.smarthome.core.thing.internal.ThingImpl@d925da0cGot the same error too, I will try to see what they have changed in the new web implementation.
It looks like total remake of the Verisure web page, this will take a while to figure out and adapt to.
Have made some progess:
Bridge configuration parameter numberOfInstallations has been removed, binding now queries API for all installations. Alarm, Broadband Connection and User Presence have got new deviceIds containing installation site id.
I will let it run for some days and also let some pre-beta testers have a go before I publish a beta to this thread.
I don’t mind testing an alpha version…
That’s gr8!
I’ll send you info in a PM!
Hi
I’m also open to test your binding 
I have
Running openhab 2.5 daily snapshot
If you need to have som of this tested
The current alfa binding is not yet adapted to the new Versure API for status updates, it still uses the old still functioning endpoints.
The next thing I will do is to adapt the binding to new endpoints for status updates as well, that will affect the thing modeling and you will have to update/adapt your local configuration (channel names and IDs) accordingly.
If that is OK with you, send me a PM!
Lovely to see that this binding is making progress (bra jobbat!). When it comes to changing the API, will it then be possible to lock and open the Yale Doorman locks through the binding? The reason I’m asking is that Athom Homey apparently takes care of that via a user contributed app (https://github.com/Charlie-Root/homey-nl-verisure/tree/bc2bf02f15b5da5467c58ad2501173dbe27b9a6f) and it would be awesome to have the same possibilities in OH2.
Hi Johan!
Lovely to see that this binding is making progress (bra jobbat!)
Tack så mycket! 
will it then be possible to lock and open the Yale Doorman locks through the binding?
I have a SmartLock connected to my Verisure system and it works to lock/unlock the SmartLock. I’ve not been able to test the functionality without having a Verisure installation with a paid subscription.
I would like to get feed-back from a user only having SmartLocks connected to the Verisure system without having a paid subscription.
The overall status is that the binding now uses the new API for both set/get channels and it is currently being tested by 3 beta-testers, as soon as I get positive feed-back from them I will post a link to the latest built jar-file in this thread. The README has been updated to reflect the changes that has been made to the things modelling/channels due to the new API.
BR
/Janne
I’m using the lock without a paid subscription so I fit the description. I will see if I can fit in some installation and testing this weekend.
I have this setup. Works fine!
Gr8!