Panda88

An updated release to deal with limitations YoLink has imposed on calls from node server to their server (it is not limiting responses from their server) Per the latest you can only call 100 times per 5 min, you can only call the same device 6 time in 1 min and you cannot call the same device within 200ms of a call - all using a rolling window. Note, a multiOutput device counts all outputs as the same device, so if updating/changing multiple outputs, please add 1sec wait between calls (code should delay calls, but to be sure). The code will now try to delay call to meet the above requirements, but if too many calls are issued simultaneously, it may not work (due to too many parallel threads). (Note, I do not think the YoLink limits work 100% correctly yet, so there are some limitations to what the code can handle - the code follows the rules above, but I cannot find the pattern to when it fails, and the issued error codes do not match what they tell me - may get fixed over time) In general one should be careful in not programming/updating the same device too often. Also - use of devices in scenes can become troublesome as calls are very close in time when changing a scene Increased the default shortPoll time to 10 min - suggest to change it if a lot of devices are used - The code spaces the calls to be 4 sec apart ShortPoll is only a safety precaution in case a MQTT packet from YoLink is missed causing the state in the node to be different than the YoLink server Fixed a bug when removing YoLink devices that are no longer registered (they get removed correctly now - I hope) Added a suspended variable to check against if calls to a device gets suspended.

Should be local - Any special reason for the delay?

Correct Selecting the message may be happening local (I believe so but I am not 100% sure) - if local it does not count - I think they play includes the selected message in one operation / call

Ok - I'll take a look again - trying to add option to show timed-out option as well (on a per node/device)

It is YoLink making this limit - I think it does not need to cause issues - It is control or status update calls. You do not need to keep querying the devices - they announce changes (which is not counted as a call) - so it is only if you change/control you devices often or you do a query update (should really be needed but there is always a chance to missing a packet being sent from device). I am working to limit the calls automatically, but not as easy if you have multiple houses on different polisys (It is my case).

Did you try the latest version. I thought i fixed it.

I should probably reword it to motion detection Actually this is also no-longer supported by the API - I guess I should remove GV5 all together Anyway, I am looking into using the latest API and maybe it will get reintroduced there again. Using the new API is more work than I initially thought, but I'll keep looking at it when I have time

A new version is available YoLink started to limit number of calls from nodeserver to their servers to 20 / min and 6 per device / min. If you have many devices a Poll will violate this and some pof the devices may be temporary offline. Changed poll to spread the query in time (4 seconds between each device). Also updated Poll to every 5 min (300s) - Poll should not be needed ideally as all changes are reported by YoLink, but in case a packet is missed ithe state will be updated during Poll. Note, if you have 75 or more devices (4 sec * 75 = 300s ) you should update shortPoll accordingly

The issue is the motion detect is not representing if motion was detected - but rather it is the ability to enable or disable motion detection on the device. I would love to add the ability to show motion detection, but there is no API for this - likely there is a call back as IFTT supports something like this, but I do not know how to implement this - remember the API used it not an official Blik API

I'll take a look tomorrow and see if I can see something

Created 0.9.64 - It is essentially a rebuild of 0.9.63 (minor bug fix as well) - I was able to recreate the original issue with 0.9.63 and 0.9.64 works ok for me now. Please give it a try. I think something went wrong in github that distributes the solution

Does anyone get a log file from the node server - please enable debug and try to start it -

@bpwwer Bob, do you have any idea what may be happening. Works fine on both my setups (PG3 and PG3x)

It is likely and issue for Bob - I sent him a message already

Correct, but it is PG3 handling the update - There have been some changes lately but it is very difficult to test as developer as you have different privileges

did you check the main polisy log (not the individual node log) - to see if there is any info? I have no idea what is happening - it seems to be PG3 - related - maybe bob can help

try to go to store - and install again - click the reinstall here button That way you do not need to reinstall

Did you try to click download log? I find the gui sometmes do not show the log, but it is there if you download it Did you click reinstall here? button when upgrading?

does the main log show something - Maybe try to power cycle your Polisy/eisy What procedure did you use - I have been using replace existing (click half way up when installing the updated node

Hi A new and updated version of the server is live now. Release note: 0.9.63 - Fixed bug with system going offline not showing. Added Smoke detector Added Siren (usable as a controllable 12V supply) Updated sensors to allow config of DON/DOF behavior. Changed use model for delays in switches, outlets (incl multi) and manipulators. Now allows programing both ON and OFF delay in 1 operation (using new drop down) - the delay settings now prepare the delay - not executing it. The main reason for this is to allow a programmed sequence of both on and off (or vice versa) - e.g. to power cycle the internet connection - or ensure a valve turns off even if internet goes down in-between 2 programming operations. (Note, yolink API changed behavior of delay so the delay will now be reset (removed) if a new command if issued after the programming of a delay)

Errors occur in the MQTT library I am using - Probably connection problem - not sure I can do much there

Sorry - it is not possible to control these parameters from the provided API. There must be a superset API, but it is not publicly available

I think you can create a scene to do this (but this is not the node server) - in the node server you would need a simple program, which can allow more flexibility

It is possible I do not update the overall node server - I'll take a look once I return from vacation. I think it is supposed to show it node server is running or not - but I does not seem to match what you describe.

The node server should restart if it detects a fault on the connection to the yolink MQTT server. So you have a debug log?