Testers for Verisure openHAB 2 binding

OK, that might be the triggering cause, maybe the binding should throttle how fast commands are scheduled. I’ve not seen the 429 logs in my production, but I will try to reproduce it from some rule.

It would be interesting to know if the 429’s are gone if you introduce a sleep.

200ms didn’t make a difference but a Thread::sleep(500) seems to have removed the issue for now.

/t

OK,cool! :slight_smile:
Maybe that is a better solution than to try to implement throttling in the binding. I’ll update the README with information about this behaviour.

No, it came back last night again :confused:
I’ll increase to 1000 ms and will see if that will help.

/t

Hi,

Now I have been stutting the documentaion a bit and I found something I’m not sure about

In items-file:

  • I see UserLocationStatus but I don’t see it in the “Verisure User Presence channel” table
  • channel="verisure:broadbandConnection:1:bc123456789:status". the :1: is that an alternative to the bridge name?
  • AlarmStatus and AlarmAlarmStatus. What are the diffrence? Also I don’t see AlarmAlarmStatus in the “Verisure Alarm channel” table

I think that’s what I’m not that sure about. But really nice work champ :slight_smile:

Keep up the good work

No still the same issue. 1 sec delay is still not the solution.
However the warnings are not 1 sec apart, so I really don’t know what’s going on.

2019-07-14 22:16:42.606 [WARN ] [nternal.handler.VerisureThingHandler] - Failed to send command, HTTP result code 429
2019-07-14 22:16:42.613 [WARN ] [nternal.handler.VerisureThingHandler] - Failed to send command, HTTP result code 429
2019-07-14 22:16:42.920 [WARN ] [nternal.handler.VerisureThingHandler] - Failed to send command, HTTP result code 429
2019-07-14 22:16:45.969 [WARN ] [nternal.handler.VerisureThingHandler] - Failed to send command, HTTP result code 429
2019-07-14 22:16:51.842 [WARN ] [nternal.handler.VerisureThingHandler] - Failed to send command, HTTP result code 429

Hi, just found out that some item tables won’t be created if you are using mysql and your database is created with utf8 character set. I altered my database to latin1 character set and then every thing was much better :slight_smile:

I don’t know if this is of any help?

alter database openhab character set=latin1;

The error I got was:

java.sql.SQLException: Column length too big for column 'value' (max = 21845); use BLOB or TEXT instead Query: CREATE TABLE IF NOT EXISTS verisure_user_email_00333 (time TIMESTAMP(3) NOT NULL, value VARCHAR(65500), PRIMARY KEY(time)) Parameters: []

I’m trying the latest jar file - I can’t find the readme file.
Anyway- Now auto discover works, and I can add my Yale doorman and it works.
NICE!

I would also like to use the ‘Verisure User Presence’ Thing to find the home/away status of users.
From the log, I can see, that the info is there:
[isCallingUser=true,webAccount=wessel.brian@gmail.com,status=ACTIVE,xbnContactId=182913,currentLocationName=,deviceId=23864464-185B-49D1-B7B1-8AB4B23C3004,name=Brian Wessel,currentLocationTimestamp=2019-07-17T06:39:41.000Z,deviceName=Brians iPhone 6s,currentLocationId=AWAY,typename=UserTracking]

  • but the auto discover doesn’t seem to bind the location info - And I’m not able to guess the correct channel

image

Can you help me solve this?
Thanks for the good work!!
/Brian

README can be found here.

2 Likes

Well spotted! :slight_smile:

  • I see UserLocationStatus but I don’t see it in the “Verisure User Presence channel” table

That was an old status not used in the new Verisure API.

  • channel="verisure:broadbandConnection:1:bc123456789:status" . the :1: is that an alternative to the bridge name?

In the case of using auto-discovery the bridge gets id 1, but it is probably confusing to have that as a sole example in the README when all other references are towards a manually configured bridge.

  • AlarmStatus and AlarmAlarmStatus . What are the diffrence? Also I don’t see AlarmAlarmStatus in the “Verisure Alarm channel” table

Same here, an old reference that I will remove.

1 Like

Does the number of logs (5) match the number of commands that you send in your goodnight process?

Could you turn on log level DEBUG and send me the logs from your goodnight process in a PM? Mask appropriate parts!

Anyway- Now auto discover works, and I can add my Yale doorman and it works.
NICE!

Cool! :slight_smile:

  • but the auto discover doesn’t seem to bind the location info - And I’m not able to guess the correct channel

I’m able to reproduce your behaviour, I have two Verisure installations, one in our home and one in our summer house.
The Verisure API exposes two variables; currentLocationName and currentLocationId. Since we now are on vacation in our summer house, the API returns:

"userTrackings":[
{
"isCallingUser":true,
"webAccount":"jannegpriv@gmail.com",
"status":"ACTIVE",
"xbnContactId":"22938123",
"currentLocationName":"HOME",
"deviceId":"C094BEA3-42FA-4536-EB4E-EA9564BB37F",
"name":"Jan Gustafsson",
"currentLocationTimestamp":"2019-07-19T09:49:20.000Z",
"deviceName":"Jans iPhone",
"currentLocationId":"79ffa72e-3e23-4edf-ba23-e4f157f77563",
"__typename":"UserTracking"
},

This seems logical, currentLocationName is a string containing my location status `HOME’ and currentLocationId is an id.

However, for my location status at our house Verisure API returns:

"userTrackings":[
{
"isCallingUser":true,
"webAccount":"jannegpriv@gmail.com",
"status":"ACTIVE",
"xbnContactId":"22938123",
"currentLocationName":null,
"deviceId":"C094BEA3-42FA-4536-EB4E-EA9564BB37F",
"name":"Jan Gustafsson",
"currentLocationTimestamp":"2019-07-15T06:06:10.000Z",
"deviceName":"Jans iPhone",
"currentLocationId":"AWAY",
"__typename":"UserTracking"
}

currentLocationName is not set (null) and currentLocationId is a string with my location status AWAY.
For me this looks like a :bug: in the API, or can someone explain the logic in this?

The binding can of course compensate for this, if currentLocationName is null then use currentLocationId instead.

Hi @jannegpriv

Would it be possible to pull one/two specific channels more often? I’m thinking about verisure:alarm:myverisure:alarm:changedByUser and verisure:alarm:myverisure:alarm:alarmStatus

I would like to know as soon a user arm/disarm the alarm and who :slight_smile:

Since Verisure seems to be picky when polling too often, I’m not sure that the binding should do it by default.
You can lower the timeout in the binding config or force a manual refresh on your bridge:

myVerisureBridge.sendCommand( RefreshType.REFRESH )

from some rule or a crontab. If you have a door bell or camera, you could maybe use that event as a trigger for a manual bridge refresh?

1 Like

I see that is not optimal to poll that often. But it is a good idea about the RefreshType.REFRESH I have a door sensor. So I could trigger it when it opens :slight_smile: maybe with a small delay

Thank you :slight_smile:

As an alternative to continuous polling. I have the Verisure app on one of my wall mounted tablets and intercept the push messages with Tasker. At any event, Tasker uses the openhab rest API to initiate a Verisure poll. This has been running very nicely, and Verisure state updates asap.

2 Likes

Hi @Daniel_Linder , that is brilliant. Thank you for the idea. Would you like to share your tasker trigger/event handler? :slight_smile:

Cool! :slight_smile: @Daniel_Linder I’m also interested in your solution, haven’t used tasker so a pointer to a good tutorial would also be appreciated. :slight_smile:

I actually got the idea from an early Verisure thread here at this forum. I will post my very simple Tasker script.

1 Like

Hi.
I had to have a look what I did, since it was a couple of years ago - and I’ve never touched it since.
:slight_smile:
I used the AutoNotification addon to tasker (if I dont remember wrongly, it did cost a few dollars).
So - in the tasker Profile I use AutoNotification to Intercept any notifications from Verisure.
The Task (called from the Profile) toggles a Virtual Switch “VerisureRefresh_Switch” using “http post”.

From there it is just a simple openhab rule that asks for a refresh from the binding whenever the virtual switch changes state.

1 Like