I have been using your fine verisure binding for some time and suddenly it stopped working. This is the output from the logs when I restart the binding:
2020-08-19 21:18:40.584 [DEBUG] [ng.verisure.internal.VerisureSession] - Status code 200 and on MyPages!
2020-08-19 21:18:40.584 [DEBUG] [ng.verisure.internal.VerisureSession] - Attempting to get all installations
2020-08-19 21:18:40.670 [DEBUG] [ng.verisure.internal.VerisureSession] - postVerisureAPI URL: https://m-api01.verisure.com/auth/login Data:empty
2020-08-19 21:18:40.671 [DEBUG] [ng.verisure.internal.VerisureSession] - Setting cookie with username xyz@xyz.com and vid
2020-08-19 21:18:40.671 [DEBUG] [ng.verisure.internal.VerisureSession] - HTTP POST Request HttpRequest[POST /auth/login HTTP/1.1]@4ad64c00.
2020-08-19 21:18:40.684 [DEBUG] [ng.verisure.internal.VerisureSession] - HTTP Response (400)
2020-08-19 21:18:40.685 [DEBUG] [ng.verisure.internal.VerisureSession] - Failed to send POST, Http status code: 400
2020-08-19 21:18:40.685 [DEBUG] [ng.verisure.internal.VerisureSession] - postVerisureAPI URL: https://m-api01.verisure.com/auth/login Data:empty
2020-08-19 21:18:40.686 [DEBUG] [ng.verisure.internal.VerisureSession] - Setting cookie with username xyz@xyz.com and vid
2020-08-19 21:18:40.687 [DEBUG] [ng.verisure.internal.VerisureSession] - HTTP POST Request HttpRequest[POST /auth/login HTTP/1.1]@4411bb2a.
2020-08-19 21:18:40.700 [DEBUG] [ng.verisure.internal.VerisureSession] - HTTP Response (400)
2020-08-19 21:18:40.700 [DEBUG] [ng.verisure.internal.VerisureSession] - Failed to send POST, Http status code: 400
2020-08-19 21:18:40.701 [WARN ] [ng.verisure.internal.VerisureSession] - Failed to set session cookie and auth login, HTTP result code: 503
2020-08-19 21:18:40.701 [WARN ] [ternal.handler.VerisureBridgeHandler] - Failed to initialize bridge, please check your credentials!
It tells me to check my credentials but I don’t think that is the real problem because my credentials have not changed. Do you have any ideas?
Jag har också sett samma fenomen på min produktionsmiljö, jag har ändrat på logiken som checkar ifall man är inloggad, vore kanon om du kunde testa denna jar-fil.
Den är baserad på kommande 2.5.8 så beroende på hur du har installerat den du kör nu kan du vara tvungen att ta bort en gammal jar-fil.
Dock löser den fixen inte orsaken till att bindingen slutade fungera skulle jag tro, något måste fått den att sluta fungera. Om du har kvar loggar skulle du kunna söka efter strängen “Exception” i både verisure och openhab-loggarna (om du har dom separerade).
Jag har hittat en bugg men den triggas bara om man har en Mice Detector och får konstigt svar på ett REST-anrop, har du en Mice Detector?
Ursäkta sent svar. Microsoft placerar alltid dessa mail i skräppost-mappen.
Tack för hjälpen! Jag ska försöka testa under dagen och återkomma. Ska även söka igenom loggarna. Har dem dock inte separerade tyvärr.
Har ingen mice detector så det borde inte vara det.
Tillägg:
Inser nu att du kanske misstolkade “restart the binding” som att den hade kraschat. Jag startade bara om den efter att jag hade slagit på debug-loggning, för att få felmeddelandet i loggen. Inte för att den hade kraschat.
I couldn’t access the jar-file. I just upgraded to OH2 2.5.7 and it seemed to fix the issue anyway. Don’t know why. When you have fixed the permissions on the jar-file I can try it anyway, but I won’t be able to tell if it fixes the problem since it is now working anyway
I also have the problem with a login error, so my question is will the binding installed via Paper UI be updated automatically to correct this login error, or will I have to use your jar file?
@jannegpriv On the 15th my verisure binding lost connection again. However a simple restart of the binding solved the issue, so it’s probably not the same error? Unfortunately I did not have DEBUG-logging activated when it occurred. Here is the log:
2020-09-15 12:51:27.817 [WARN ] [ng.verisure.internal.VerisureSession] - Failed to send a POST to the API java.io.EOFException: HttpConnectionOverHTTP@6d23c333::DecryptedEndPoint@349847a5{m-api01.verisure.com/195.170.189.34:443<->/192.168.1.27:56994,OPEN,fill=-,flush=-,to=24102/0}
2020-09-15 12:57:24.306 [WARN ] [ng.verisure.internal.VerisureSession] - Failed to send a POST to the API java.net.SocketTimeoutException: Connect Timeout
2020-09-15 13:09:33.592 [WARN ] [ng.verisure.internal.VerisureSession] - Failed to send a POST to the API java.net.SocketTimeoutException: Connect Timeout
2020-09-15 13:09:48.594 [WARN ] [ng.verisure.internal.VerisureSession] - Failed to send a POST to the API java.net.SocketTimeoutException: Connect Timeout
2020-09-15 13:15:32.136 [WARN ] [ng.verisure.internal.VerisureSession] - Failed to send a POST to the API java.io.EOFException: HttpConnectionOverHTTP@63e24fa3::DecryptedEndPoint@5aafa55e{m-api01.verisure.com/195.170.189.34:443<->/192.168.1.27:57020,OPEN,fill=-,flush=-,to=38470/0}
2020-09-15 13:33:07.825 [WARN ] [ng.verisure.internal.VerisureSession] - Failed to send a POST to the API java.net.SocketTimeoutException: Connect Timeout
2020-09-15 13:33:19.579 [WARN ] [ng.verisure.internal.VerisureSession] - Failed to send a POST to the API java.io.EOFException: HttpConnectionOverHTTP@445c78e::DecryptedEndPoint@4b3a919c{m-api01.verisure.com/195.170.189.34:443<->/192.168.1.27:57042,OPEN,fill=-,flush=-,to=11353/0}
2020-09-15 13:38:53.307 [WARN ] [ng.verisure.internal.VerisureSession] - Failed to send a POST to the API java.io.EOFException: HttpConnectionOverHTTP@650172aa::DecryptedEndPoint@5d69b236{m-api01.verisure.com/195.170.189.34:443<->/192.168.1.27:57048,OPEN,fill=-,flush=-,to=12802/0}
2020-09-15 13:44:18.636 [WARN ] [ng.verisure.internal.VerisureSession] - Failed to send a POST to the API java.net.SocketTimeoutException: Connect Timeout
2020-09-15 13:50:12.895 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.NullPointerException: null
at org.openhab.binding.verisure.internal.dto.VerisureBaseThingDTO$Installation.equals(VerisureBaseThingDTO.java:376) ~[?:?]
at org.openhab.binding.verisure.internal.dto.VerisureBaseThingDTO$Data.equals(VerisureBaseThingDTO.java:231) ~[?:?]
at org.openhab.binding.verisure.internal.dto.VerisureBaseThingDTO.equals(VerisureBaseThingDTO.java:150) ~[?:?]
at org.openhab.binding.verisure.internal.VerisureSession.notifyListenersIfChanged(VerisureSession.java:509) ~[?:?]
at org.openhab.binding.verisure.internal.VerisureSession.updateEventLogStatus(VerisureSession.java:878) ~[?:?]
at org.openhab.binding.verisure.internal.VerisureSession.lambda$2(VerisureSession.java:532) ~[?:?]
at java.util.concurrent.ConcurrentHashMap.forEach(ConcurrentHashMap.java:1597) ~[?:1.8.0_262]
at org.openhab.binding.verisure.internal.VerisureSession.updateStatus(VerisureSession.java:519) ~[?:?]
at org.openhab.binding.verisure.internal.VerisureSession.refresh(VerisureSession.java:119) ~[?:?]
at org.openhab.binding.verisure.internal.handler.VerisureBridgeHandler.refreshAndUpdateStatus(VerisureBridgeHandler.java:181) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:1.8.0_262]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) ~[?:1.8.0_262]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) ~[?:1.8.0_262]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) ~[?:1.8.0_262]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_262]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_262]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_262]
Edit:
And another thing I just noticed is that I can’t manage to get the output from the verisure binding to its own log file as described in the openhab documentation. It works for other bindings. This is the entries in org.ops4j.pax.logging.cfg:
The last two entries are what is created by default from openhab when running log:set DEBUG org.openhab.binding.verisure. That works, the debug output is coming to the openhab.log, but not to verisure.log.
Thank’s for the exception stack trace, it is the Eventlog that is null on that row. I’ve seen some similar problems with API queries for Eventlog that fails and then the code fails to handle the fact that the Eventlog is null. I will add more null checks for that in a future fix.
Regarding your problem with not logging to a separate file I have no clue what causes that. I have almost identical config as you have and it works for me.
Verisure has changed the authentication process a couple of weeks ago so the official binding in 3.1.0 does not work anymore. Please see the official binding thread!
