If you have tested an earlier version of the binding and configured things in the PaperUI, I strongly suggest to start all over again and remove all things-configuration including the bridge. NOTE: The things modelling have been changed since previous versions, consult the updated README!
The binding works great in general. Thanks for all the hard work!
But when the VeriSure webservice has some issue and comes with an unexpected response - in this case the alarm stayed in a âpreparing to disarmâ state because there was some âAPI issueâ - then the response (see below) is not handled by the parsing logic:
2019-06-12 06:54:41.951 [INFO ] [ng.verisure.internal.VerisureSession] - Status code 503 body <!DOCTYPE html >
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>My Pages is temporarily unavailable</title>
<style type="text/css">
html, body {
color: #666;
...
</head>
<body>
<div class="main logo">
<div class="verisure-266x56"></div>
</div>
<div class="main box">
<!-- Any relative links or includes on the error page itself will be resolved to absolute URLs by the
client according to the URL in its address bar.
So images, CSS files, external JavaScript files, etc. will be referenced using incorrect URLs if the
links on your error page are page-relative -->
<div class="header">
My Pages is temporarily unavailable, please try again later.
</div>
<div class="flag-wrapper">
<div class="se"></div>
<div>Mina Sidor Àr för tillfÀllet inte tillgÀngligt, försök igen senare.</div>
</div>
...
The alarm status remained PENDING. I tried a few times to set the alarm state to DISARMED, same status. The funny thing is that the alarm was actually already disabled the first time (or maybe the second attempt). The VeriSure App gave a disarm pending state as well (donât recall the exact message). After a while (I checked about 20 minutes later) everything was ok and the status was reported correct (DISARMED).
Perhaps you can check for a âMy Pages is temporarily unavailableâ text?
I saw the same logs in my production environment this morning between 06.21 and 07.13, so it seems like the Verisure service experienced some problems during that time.
Since we get a 503 HTTP response the fix will be to catch that when determining if weâre still are logged in, and then wait for the next poll interval to see if the Verisure service is up again.
Iâve also found a couple of other log printouts that I will try to fix in the next build.
The binding currently logs a lot, especially using DEBUG, I should probably move some logs to use TRACE level instead.
Fortunately my kids are grown up, so me and my better half have got plenty of time to spend on our hobbies.
But since I made a temp. fix for the issue, it looks like verisure has decided to change to another API server from today around 14.00 (so it was an easy fix this time), I will perhaps have some time for herring and snaps on Friday
The binding should probably implement automatic handling of this since we now know the failure code for when this happens. Hopefully the change will be done for some time to come, but you never know.
I had the updated binding running for 2 days without issues. Status is reported properly, alarm on.off works. I noticed just two small hickups in openhab.log, most likely due to failure on VeriSure webservice:
11:00:35.003 [WARN ] [ng.verisure.internal.VerisureSession] - Failed to set session cookie and auth login, HTTP result code: 500
11:10:35.717 [WARN ] [ng.verisure.internal.VerisureSession] - Failed to set session cookie and auth login, HTTP result code: 500
I would say it is stable and earns its place in the openhab-addons âhall of fameâ.
I might have something here.
I have a goodnight process that among other things closes all locks. Maybe I have to introduce a sleep statement or something to slow down API access?
/t
2019-07-06 22:50:53.366 [INFO ] [ipse.smarthome.model.script.Wallmote] - Close all locks
2019-07-06 22:50:54.533 [WARN ] [nternal.handler.VerisureThingHandler] - Failed to send command, HTTP result code 429
2019-07-06 22:50:55.142 [WARN ] [nternal.handler.VerisureThingHandler] - Failed to send command, HTTP result code 429
2019-07-06 22:50:55.235 [WARN ] [nternal.handler.VerisureThingHandler] - Failed to send command, HTTP result code 429
2019-07-06 22:50:55.518 [WARN ] [nternal.handler.VerisureThingHandler] - Failed to send command, HTTP result code 429
(if the familiy agrees 
)
