Will have a look tomorrow.
Thanks! I can conform that proper URL encoding is happening now. 
Gr8! 
Well, that might be a challenge. On the Mypages website there is no status info and all that can be deducted from the Python tool created by persandstrom, is that the simple Motion Sensor is tagged as PIR2 type device. Not very usefullâŠ
Looks like that info can only be obtained using push messages from Google Cloud Messaging, like the way the App works. 
UPDATE: Thatâs probably because the motion detection is only a âtransientâ stateâŠ
Looks like that info can only be obtained using push messages from Google Cloud Messaging, like the way the App works.
That would be the next thing, once/if this binding gets official, to start to look into changing API to the one that the mobile app uses.
1 Like
Now that the bridge and alarm are online and reporting their status (again, thanks for your support), I started looking at the other devices and I can conform that the following Things and Channels work in my setup:
- alarm - All work (except setAlarmStatus not yet tested).
- smokeDetector - All work.
- doorWindowSensor - All work.
- siren - temperature and lastUpdate work; humidity has NULL value.
- nightControl - temperature and lastUpdate work; humidity has NULL value.
- broadbandConnection - all work.
Not sure why the siren and and nightControl give NULL value. Iâve tried with and without UoM Dimensionless.
Things definition:
Thing siren kitchenSiren "Siren" [deviceId="<redacted>"]
Thing nightControl corridorNightControl "Night Control" [deviceId="<redacted>"]
Items definition:
Number VS_NightControlHum "Humidity NightControl [%.0f]" {channel="verisure:nightControl:myverisure:corridorNightControl:humidity"}
Number VS_KitchenHum "Humidity Kitchen [%.0f %unit%]" {channel="verisure:siren:myverisure:kitchenSiren:humidity"}
I probably overlooked something, but what�
This is why it is good to have observant testers!
Not all Verisure components supports Humidity, however the binding internally uses the same model representation for the JSON that the API returns, VerisureClimateBaseJSON.
Hence the channel humidity is âinheritedâ to all Verisure things/devices that are instances of VerisureClimateBaseJSON.
One can argue that e.g. the Smoe Detector exists in different HW revisons, the first revisions did not have support for temperature and humidity, I think (but I might be wrong), that then temperature was implemented and in the latest revions both temperature and humidity.
However, for Nigh Control and Siren. I think that only temperature has been supported, but who knows, in later upcoming revisions maybe humidity will be supported.
Hence, we have a choice of always having channel humidity for all Climate Devices, or I can change to only have humidity for those Climate Devices that supports it.
What do you think?
I had another look at the output of the vsure Python tool, and indeed, not all support humidity:
"climateValues": [
{
"time": "2019-03-21T12:54:16.000Z",
"deviceLabel": "<redacted>",
"deviceType": "HOMEPAD1",
"temperature": 18.4,
"deviceArea": "overloop"
},
{
"temperature": 18.5,
"deviceLabel": "<redacted>",
"humidity": 64.0,
"deviceType": "SMOKE2",
"time": "2019-03-21T08:00:45.000Z",
"deviceArea": "garage"
},
{
"temperature": 19.0,
"deviceLabel": "<redacted>",
"humidity": 64.0,
"deviceType": "SMOKE2",
"time": "2019-03-21T08:00:57.000Z",
"deviceArea": "overloop"
},
{
"time": "2019-03-21T13:00:22.000Z",
"deviceLabel": "<redacted>",
"deviceType": "SIREN1",
"temperature": 19.0,
"deviceArea": "keuken"
},
{
"time": "2019-03-21T13:04:56.000Z",
"deviceLabel": "<redacted>",
"deviceType": "PIR2",
"temperature": 18.0,
"deviceArea": "garage"
}
],
Looks like the HOMEPAD1 is the VeriSure Night Controller and the PIR2 is the âsimpleâ (non-Photo) Motion Sensor (on a side note: it should be possible to get temperature readings from this device. 
). And indeed, they donât report humidity values.
I think the easy approach would be to just âfixâ the documentation (read: remove the references to humidity) and add some comments on the versions of these devices. Would be great if we somehow can determine the version from e.g. the deviceLabel, otherwise I would propose to keep things as is and only update the documentation.
If you want, I can help updating the documentation.
UPDATE: I did notice during testing that sometimes I had to restart OH before Item changes were picked up (not always). Restarting the binding was not working either in those cases.
UPDATE 2: Tested arm/disarm of alarm and confirming the setAlarmStatus also works in my setup.
otherwise I would propose to keep things as is and only update the documentation.
I go for that option!
If you want, I can help updating the documentation.
Since the binding is under final review, Iâll update the README file.
UPDATE: I did notice during testing that sometimes I had to restart OH before Item changes were picked up (not always). Restarting the binding was not working either in those cases.
OK, not seen that. Were there any specific items that you saw this behaviour on?
Could be an OH platform issue.
UPDATE 2: Tested arm/disarm of alarm and confirming the setAlarmStatus also works in my setup.
Good to hear! 
I suspect it is. I noticed for instance that when changing humidity items (for devices that do support it) when playing with UoM/Dimensionless, the change was not always picked up without reboot.
README has been updated to reflect current support for channel humidity for some climate devices.
1 Like
Iâve updated the binding with support user presence status for many users, README has been updated and a new jar-file has been uploaded to original post.
1 Like
Will definitely give it a try. Thanks!
Seems like Verisure is introducing a new webpage and app in the coming weeks, this will most probably affect the implementation of the binding.
In Swedish:
VI LANSERAR SPĂNNANDE NYHETER
Som marknadsledare i Sverige och Europa Àr vi starkare Àn nÄgonsin. Nu tar vi nÀsta steg i vÄr fortsatta innovationsresa och lanserar en ny version av Mina Sidor och Verisure App . Allt för att ge dig en Ànnu bÀttre anvÀndarupplevelse. Lanseringen sker successivt under kommande veckor vilket innebÀr att olika medlemmar i familjen under en kort period kan ha olika versioner.
Where was this posted? On the âMyPagesâ site? There is nothing (yet) on the Dutch website.
I suppose it is also related to the move away from GCMâŠ
I got an eMail today.
Seems like the Web API has not been changed after all, Iâve compiled a new version of the binding with the latest changes made after code review.
The biggest change in this version is that the deviceId (Verisure ID) now can be represented as:
- ABCD_WXYZ
- ABCDWXYZ
- ABCD WXYZ
If auto-discovery is used the binding will generate deviceId without any delimter, e.g. ABCDWXYZ.
README has been updated.
Latest compiled jar-file based on OH2.5 but it also works for OH2.4.
md5sum:
openhab@openhab2:/usr/share/openhab2/addons $ md5sum org.openhab.binding.verisure-2.5.0-SNAPSHOT.jar
290940a1d5a5706af6412b9c4bdc7493 org.openhab.binding.verisure-2.5.0-SNAPSHOT.jar
1 Like
Great work. Thanks a lot. I just added all my Verisure sensors to Openhab. So far all seems to work except the arming of the alarm. But I would probably disable it anyway from my system.
One thing I noticed is that it seems that the user PIN cannot start with a â0â. It will just âget lostâ.
I have been considering to install additional sensors parallel to Verisure but now I do not need to do this anymore 
It seems the binding is not really working for me. Yesterday, when I configured all the things, all the items were updated. Only the Bridget Status kept showing â-â but everything seemed to work. The only thing that did not work was to set the alarm status from the Alarm-thing. The status changed to pending and it did not update the alarm status. Not a problem for me since I was only testing this and will probably not use it.
The main issue for me now is that the data does not seem to get updated at all. All the time stamps still show yesterdayâs date and status of things donât seem to change.
Any idea what the problem is?