Version 2.0.9 bugs, errors and suggestions

@crazyfin I use Mojave 10.14.6 on my minimac late 2012 and don’t have the issues that you describe.


Skickat från min iPad med Tapatalk

Wohoo!

After upgrading to High Sierra 10.13.6 the Verisure-plugin works fine again. Thanks to @FlyingDiver!

I had some USB serial driver issues (of course) for my RFXtrx433E unit.
Even though I followed the steps described in https://www.indigodomo.com/blog/2018/01 ... orkaround/ I was struggling to get the unit being recognized as a serial device. I was able to see RFXtrx433E in the System Profiler report but it did not show up as a serial device.

I am not sure what in the end fixed it but it was after I followed parts of the steps described in https://superuser.com/questions/1135730 ... sx/1136084 that I was able to get it to work and, especially the part where the command "csrutil disable" is described. (And then when it was working I enabled csrutil again.)

All good now! Puih.... took just the whole Sunday for me...

Looks like that Verisure has tighten their trigger level for how often one can poll for alarm status updates....

I have set the plugin to poll every 15th second and I have now during the last 2 weeks encountered the error message

Data: {"errorGroup":"TOO_MANY_REQUESTS","errorCode":"AUT_00021","errorMessage":"Request limit has been reached"}

Here is a full sequence of the error log:

Code: Select all

2020-08-20 00:05:21.673   Verisure v2 Error   Error in plugin execution runConcurrentThread:
Traceback (most recent call last):
  File "plugin.py", line 331, in runConcurrentThread
  File "plugin.py", line 177, in refreshData
  File "/Library/Application Support/Perceptive Automation/Indigo 7.4/Plugins/VerisureV2.indigoPlugin/Contents/Server Plugin/verisure/session.py", line 191, in get_overview
  File "/Library/Application Support/Perceptive Automation/Indigo 7.4/Plugins/VerisureV2.indigoPlugin/Contents/Server Plugin/verisure/session.py", line 18, in _validate_response
ResponseError: Invalid response, status code: 429 - Data: {"errorGroup":"TOO_MANY_REQUESTS","errorCode":"AUT_00021","errorMessage":"Request limit has been reached"}
2020-08-20 00:05:21.676   Verisure v2 Error   plugin runConcurrentThread function returned or failed (will attempt again in 10 seconds)

2020-08-20 00:05:43.680   Verisure v2 Error   Error in plugin execution runConcurrentThread:
Traceback (most recent call last):
  File "plugin.py", line 331, in runConcurrentThread
  File "plugin.py", line 180, in refreshData
  File "/Library/Application Support/Perceptive Automation/Indigo 7.4/Plugins/VerisureV2.indigoPlugin/Contents/Server Plugin/verisure/session.py", line 191, in get_overview
  File "/Library/Application Support/Perceptive Automation/Indigo 7.4/Plugins/VerisureV2.indigoPlugin/Contents/Server Plugin/verisure/session.py", line 18, in _validate_response
ResponseError: Invalid response, status code: 429 - Data: {"errorGroup":"TOO_MANY_REQUESTS","errorCode":"AUT_00021","errorMessage":"Request limit has been reached"}
2020-08-20 00:05:43.680   Verisure v2 Error   plugin runConcurrentThread function returned or failed (will attempt again in 10 seconds)

Only way to stop this is to disable the plugin and wait at least 1 minute and then enable the plugin again.
It looks like the plugin is hard coded to make a new poll attempt every 10th second on errors no matter what polling frequency I have set in the configuration.

Would be great if the pause between new attempts could increase with an increasing interval so that eventually Verisure will accept a new poll.
Maybe a max pause of 5-10 minutes would be good as well? (Or even better, let the user set a min pause and max pause on retries when an error has been detected. )

This morning I had a new type of error message in the Verisure plugin:

Code: Select all

2020-10-07 06:03:03.001   Verisure v2 Error   Error in plugin execution runConcurrentThread:
Traceback (most recent call last):
  File "plugin.py", line 331, in runConcurrentThread
  File "plugin.py", line 177, in refreshData
  File "/Library/Application Support/Perceptive Automation/Indigo 7.4/Plugins/VerisureV2.indigoPlugin/Contents/Server Plugin/verisure/session.py", line 191, in get_overview
  File "/Library/Application Support/Perceptive Automation/Indigo 7.4/Plugins/VerisureV2.indigoPlugin/Contents/Server Plugin/verisure/session.py", line 18, in _validate_response
ResponseError: Invalid response, status code: 503 - Data: {"errorGroup":"SERVICE_UNAVAILABLE","errorCode":"SYS_00004","errorMessage":"XBN Database is not activated"}

After the error above the plugin seems to end up being stuck in a bad state and keeps on generating the following error message on every attempt every 10th second from now on:

Code: Select all

2020-10-07 06:27:18.925   Verisure v2 Error   Error in plugin execution runConcurrentThread:

Traceback (most recent call last):
  File "plugin.py", line 326, in runConcurrentThread
  File "plugin.py", line 162, in doLogin
  File "plugin.py", line 210, in refreshData
KeyError: 'userTracking'

2020-10-07 06:27:18.926   Verisure v2 Error   plugin runConcurrentThread function returned or failed (will attempt again in 10 seconds)

Restarting the plugin does not help and I am starting to suspect that Verisure has donee some change or that they are currently having issues with the API.
I am able to login to "My Pages" at Verisure on the web home page.

If I run the "vsure" python code from Per Sandströms library manually in a terminal window I am able to get status from my alarm so it feels there is something wrong with the plugin in Indigo?

@howartp:
It looks like the error is caused by line 210 in "plugin.py":

Code: Select all

userTracking = self.overview['userTracking']

When I run Per Sandström's Python module and I do the command

Code: Select all

vsure <username> <pwd> installations

I do not get any keys with "userTracking" as the name?

According to Per Sandström's Github page the commands available are:

Code: Select all

usage: vsure [-h] [-i INSTALLATION] [-c COOKIE]
             username password
             {installations,overview,armstate,set,climate,eventlog,capture,imageseries,getimage,vacationmode,door_window,test_ethernet}

So there seems to be no key named "userTracking"?

@tazswe: Do you currently have problems with the Verisure V2 plugin in Indigo or is yours working fine?

When I have an refresh time of 5 seconds it won’t work at all but when I increase it to 15 seconds I will have exactly the same errors as you CrazyFin.

If howartp will have the time to have a look at it, please be free to log into my system and if you have forgotten the password, pls let me know.


Skickat från min iPad med Tapatalk

Looks like other people who use Per Sandström's Verisyre plugin have encountered the same problems with the key "userTab" not working anymore:
https://github.com/persandstrom/python- ... issues/124

Up until recentely when I called the get_overview() command I got a "userTracing" tab in the json reply but now its missing. Anybody knows if Verisure hidden it or if the information is avalible somewhere else?

@howartp
Another observation based on the post I found at Per Sandström's Github is indeed the fact that "overview" does not return any key with value "userTracing":

Code: Select all

{
    "accountPermissions": {
        "accountPermissionsHash": "xxxxxxxxxxxxxxxxxxxxx"
    },
    "armState": {
        "statusType": "DISARMED",
        "date": "2020-10-15T14:04:12.000Z",
        "name": "xxxxxx",
        "changedVia": "CODE"
    },
    "smartPlugs": [
        {
            "icon": "LIGHT",
            "isHazardous": false,
            "deviceLabel": "xxxxxxxx",
            "area": "xxxxxx",
            "currentState": "OFF",
            "pendingState": "NONE"
        }
    ],
    "doorLockStatusList": [
        {
            "deviceLabel": "xxxxxxxx",
            "area": "xxxxxx",
            "method": "AUTO",
            "lockedState": "LOCKED",
            "currentLockState": "LOCKED",
            "pendingLockState": "NONE",
            "eventTime": "2020-10-15T15:53:12.000Z",
            "secureModeActive": false,
            "motorJam": false,
            "paired": true
        }
    ],
    "climateValues": [
        {
            "deviceLabel": "xxxxxxxxx",
            "deviceArea": "xxxxxxxxx",
            "deviceType": "xxxxxxxx",
            "temperature": 21.3,
            "time": "2020-10-15T15:56:51.000Z"
        }
    ],
    "installationErrorList": [],
    "ethernetModeActive": true,
    "ethernetConnectedNow": true,
    "heatPumps": [],
    "latestEthernetStatus": {
        "latestEthernetTestResult": true,
        "testDate": "2020-10-15T15:45:20.000Z",
        "protectedArea": "xxxxxxxxxxxx",
        "deviceLabel": "xxxxxxx"
    },
    "customerImageCameras": [
        {
            "motionDetectorMode": "xxxxxxxxx",
            "area": "xxxxxxxxx",
            "deviceLabel": "xxxxxxxx",
            "numberOfNotViewedImageSeries": 0,
            "imageResolution": "HIGHER",
            "accelerometerMode": "xxxxxxxxx",
            "capability": "xxxxxxxxxxxxxx"
        }
    ],
    "eventCounts": [],
    "doorWindow": {
        "reportState": true,
        "doorWindowDevice": [
            {
                "deviceLabel": "xxxxxxxx",
                "area": "xxxxxxxxxx",
                "state": "CLOSE",
                "wired": false,
                "reportTime": "2020-10-15T15:53:13.000Z"
            }
        ]
    }
}


(I have removed actual data and replaced it with x:es in some places)

Hi both

Give https://github.com/howartp84/Verisure/r ... tag/2.0.10 a try

The Verisure API used to allow you to have multiple locations (homes) with an Alarm in each home, so I had to enumerate the location to find which Home your Alarm was in.

They've now removed that and only allow one Alarm per account, and changed the API accordingly.

I think this release sorts it, though using the test account (I can't remember which of your logins I'm using) the "date" value stays at 2019-12-11 instead of 2020-11-10)

You will need to edit your "Alarm" device and pick the new "My Alarm" location.

See how it goes before I push it live.

Peter

Wohoooo!

Initial tests with 15 sec polling interval seems to work perfectly fine now!
If I set it to 5 seconds I get the "too many requests" error message:

Code: Select all

2020-11-10 23:10:41.555   Verisure v2 Error   Error in plugin execution runConcurrentThread:
Traceback (most recent call last):
  File "plugin.py", line 333, in runConcurrentThread
  File "plugin.py", line 180, in refreshData
  File "/Library/Application Support/Perceptive Automation/Indigo 7.4/Plugins/VerisureV2.indigoPlugin/Contents/Server Plugin/verisure/session.py", line 191, in get_overview
  File "/Library/Application Support/Perceptive Automation/Indigo 7.4/Plugins/VerisureV2.indigoPlugin/Contents/Server Plugin/verisure/session.py", line 18, in _validate_response
ResponseError: Invalid response, status code: 429 - Data: {"errorGroup":"TOO_MANY_REQUESTS","errorCode":"AUT_00021","errorMessage":"Request limit has been reached"}
2020-11-10 23:10:41.556   Verisure v2 Error   plugin runConcurrentThread function returned or failed (will attempt again in 10 seconds)

However, when this happens the retry time should be at least 30 seconds since it seems that the hardcoded 10 seconds interval will keep on generating the "too many requests" error.
Even better would be that it extends those 30 seconds to 1 minute and then 2 minutes up and until a maximum delay time of 10 minutes.

I have tested various polling times and it seems to me that Verisure has now set a low limit of 15 seconds polling time since the auto-retry of 10 seconds fails. Setting to 5 seconds polling time generates "too many requests" almost immediately. Could you have a 10 second (or 11 second) polling time in the list to choose from so that I can try to find the lowest possible polling time?

Anyway, I am sooooo happy that it seems to work again which means that all my triggers connected to arming home, arming away and disarming are now working again.

Ok, I’ll have to trap the error then handle it; my copy is set to 60 seconds because I don’t need it to do anything except for testing

I’ll come back to it sometime this week.

Peyet


Sent from my iPhone using Tapatalk Pro

Thanks howartp,

I have upgraded the plugin to version 2.10.
For some reason I had to remove the old plugin to get it to work, I had the same problem at an earlier upgrade.

Unfortunately the polling time 5 sec is not working.

It is important for me to have as short a polling time as possible so that the door does not have time to open and lock again without it being registered.

If the problem is that Verisure does not allow more than a certain Numbers of status requests let’s find out how low we can go.

I suggest status update rates as follows.
5 sec
7 sec
9 sec
11 sec
13 sec
15 sec
1 min
1 hour


Skickat från min iPad med Tapatalk

@tazswe: I have found out that 10 or even 11 seconds polling time seems to be the new lowest intervall.

As soon as I set the interval to 5 seconds I start to get the error message "TOO MANY REQUESTS"...

Crazyfin, you are probably right, but why guess, let’s find out.
I guess it’s an easy update of the plugin to change update rates, there are a lot of long polling times in current plugin that are of no interest.

Agree.

@howartp: Could you allow polling times 5,6,7,8,9,10,11,12,13,14,15 and then 30, 45, 1 min, 2 min, 3 min, 4 min, 5 min and then end with 10 min?
Or even better, let the user decide the polling time by entering it in number of seconds?

Agree.

@howartp: Could you allow polling times 5,6,7,8,9,10,11,12,13,14,15 and then 30, 45, 1 min, 2 min, 3 min, 4 min, 5 min and then end with 10 min?
Or even better, let the user decide the polling time by entering it in number of seconds?

https://github.com/howartp84/Verisure/r ... tag/2.0.11