Panda88

Did you do a power cycle? Another option is to generate a new token in the yolink app If not i would open a ticket

I have seen this as well - on more than 1 node server - I have restarted polisy and it went away, Not sure what caused it

I doubt it - unless the web interface which I assume is operating on a different port

Hi I have 2 system setup. One is working flawless and the other has issues on and off. I though there may be issues with the envisalink so I ordered a new one but it remains the same. It sometimes will not start - it retrieves the system (all nodes etc so it must be talking to the envisalink) but when it comes to panel1 it states there is no connection - some times it manages to get by this state and I will work ok Any idea log: 2023-12-16 14:54:08,500 Thread-51 udi_interface DEBUG nslib:start: In start() for node panel1... 2023-12-16 14:54:08,502 Command udi_interface.interface DEBUG interface:_handleResult: add node response: {'id': '53aad9c8-a83b-4776-9cc5-bd7b5a272909', 'uuid': '00:0d:b9:52:d9:38', 'profileNum': 5, 'address': 'panel1', 'name': 'Alarm Panel', 'nodeDefId': 'PANEL', 'nls': None, 'hint': '16843008', 'controller': 0, 'primaryNode': 'panel1', 'private': None, 'isPrimary': 1, 'enabled': 1, 'timeAdded': 1677029040739, 'timeModified': 1702767248422, 'dbVersion': 1} 2023-12-16 14:54:32,144 MQTT udi_interface.interface DEBUG interface:_message: QUEUING incoming message shortPoll 2023-12-16 14:54:32,146 Command udi_interface.interface DEBUG interface:_parseInput: DEQUEING shortPoll 2023-12-16 14:54:32,147 Thread-52 udi_interface DEBUG evldscns:shortPoll: In shortPoll()... 2023-12-16 14:54:32,149 Thread-52 udi_interface INFO nodes:shortPoll: Establishing connection to EnvisaLink device... 2023-12-16 14:54:32,150 Thread-52 udi_interface DEBUG evltpi_dsc:_connect_evl: Connecting to EnvisaLink device... 2023-12-16 14:54:32,150 Thread-52 udi_interface DEBUG evltpi_dsc:_connect: In connect()... 2023-12-16 14:54:32,153 Thread-52 udi_interface DEBUG evltpi_dsc:_get_next_cmd_seq: In _get_next_cmd_seq()... 2023-12-16 14:54:32,154 Thread-52 udi_interface ERROR evltpi_dsc:_get_next_cmd_seq: TCP Connection to EnvisaLink unexpectedly closed. Socket error: [Errno 54] Connection reset by peer 2023-12-16 14:54:32,155 Thread-52 udi_interface ERROR evltpi_dsc:_connect_evl: Invalid sequence received from EnvisaLink upon connection: None 2023-12-16 14:54:32,157 Thread-52 udi_interface.node DEBUG node:setDriver: panel1:Alarm Panel Reporting set ST to 0 to Polyglot 2023-12-16 14:54:32,158 Thread-52 udi_interface.node DEBUG node:reportDriver: Updating value to 0 2023-12-16 14:54:32,159 Thread-52 udi_interface WARNING nodes:shortPoll: Could not connect to EnvisaLink device at 192.168.2.223. 2023-12-16 14:54:32,160 Thread-52 udi_interface.custom DEBUG custom:__setitem__: CUSTOM: no_connect = Could not connect to EnvisaLink device. Please check the network and Custom Configuration Parameter values for the nodeserver. ...saving 2023-12-16 14:54:32,161 Thread-52 udi_interface.custom INFO custom:_save: Sending data notices to Polyglot. 2023-12-16 14:54:32,163 Thread-1 udi_interface.interface DEBUG interface:_send: PUBLISHING {'set': [{'address': 'panel1', 'driver': 'ST', 'value': '0', 'uom': 2, 'text': None}]} 2023-12-16 14:54:32,165 Thread-1 udi_interface.interface DEBUG interface:_send: PUBLISHING {'set': [{'key': 'notices', 'value': {'no_connect': 'Could not connect to EnvisaLink device. Please check the network and Custom Configuration Parameter values for the nodeserver.'}}]} 2023-12-16 14:54:32,449 MQTT udi_interface.interface DEBUG interface:_message: QUEUING incoming message notices 2023-12-16 14:54:32,451 Command udi_interface.interface DEBUG interface:_parseInput: DEQUEING notices 2023-12-16 14:54:32,452 Command udi_interface.custom DEBUG custom:load: CUSTOM: load {'no_connect': 'Could not connect to EnvisaLink device. Please check the network and Custom Configuration Parameter values for the nodeserver.'} 2023-12-16 14:54:32,453 Command udi_interface.custom DEBUG custom:load: CUSTOM: -- checking no_connect / Could not connect to EnvisaLink device. Please check the network and Custom Configuration Parameter values for the nodeserver. 2023-12-16 14:54:32,489 MQTT udi_interface.interface INFO interface:_message: Successfully set key = notices 2023-12-16 14:54:32,492 MQTT udi_interface.interface INFO interface:_message: Successfully set panel1 :: ST to 0 UOM 2 2023-12-16 14:55:02,124 MQTT udi_interface.interface DEBUG interface:_message: QUEUING incoming message shortPoll 2023-12-16 14:55:02,126 Command udi_interface.interface DEBUG interface:_parseInput: DEQUEING shortPoll 2023-12-16 14:55:02,127 Thread-53 udi_interface DEBUG evldscns:shortPoll: In shortPoll()... 2023-12-16 14:55:02,129 Thread-53 udi_interface INFO nodes:shortPoll: Establishing connection to EnvisaLink device... 2023-12-16 14:55:02,130 Thread-53 udi_interface DEBUG evltpi_dsc:_connect_evl: Connecting to EnvisaLink device... 2023-12-16 14:55:02,131 Thread-53 udi_interface DEBUG evltpi_dsc:_connect: In connect()... 2023-12-16 14:55:02,133 Thread-53 udi_interface DEBUG evltpi_dsc:_get_next_cmd_seq: In _get_next_cmd_seq()... 2023-12-16 14:55:02,134 Thread-53 udi_interface ERROR evltpi_dsc:_get_next_cmd_seq: TCP Connection to EnvisaLink unexpectedly closed. Socket error: [Errno 54] Connection reset by peer 2023-12-16 14:55:02,135 Thread-53 udi_interface ERROR evltpi_dsc:_connect_evl: Invalid sequence received from EnvisaLink upon connection: None 2023-12-16 14:55:02,136 Thread-53 udi_interface.node DEBUG node:setDriver: panel1:Alarm Panel Reporting set ST to 0 to Polyglot 2023-12-16 14:55:02,137 Thread-53 udi_interface.node DEBUG node:reportDriver: Updating value to 0 2023-12-16 14:55:02,138 Thread-53 udi_interface WARNING nodes:shortPoll: Could not connect to EnvisaLink device at 192.168.2.223. 2023-12-16 14:55:02,139 Thread-53 udi_interface.custom DEBUG custom:__setitem__: CUSTOM: no_connect = Could not connect to EnvisaLink device. Please check the network and Custom Configuration Parameter values for the nodeserver. ...saving 2023-12-16 14:55:02,140 Thread-53 udi_interface.custom INFO custom:_save: Sending data notices to Polyglot. 2023-12-16 14:55:02,144 Thread-1 udi_interface.interface DEBUG interface:_send: PUBLISHING {'set': [{'address': 'panel1', 'driver': 'ST', 'value': '0', 'uom': 2, 'text': None}]} 2023-12-16 14:55:02,147 Thread-1 udi_interface.interface DEBUG interface:_send: PUBLISHING {'set': [{'key': 'notices', 'value': {'no_connect': 'Could not connect to EnvisaLink device. Please check the network and Custom Configuration Parameter values for the nodeserver.'}}]} 2023-12-16 14:55:02,260 MQTT udi_interface.interface INFO interface:_message: Successfully set panel1 :: ST to 0 UOM 2 2023-12-16 14:55:02,302 MQTT udi_interface.interface DEBUG interface:_message: QUEUING incoming message notices 2023-12-16 14:55:02,305 MQTT udi_interface.interface INFO interface:_message: Successfully set key = notices 2023-12-16 14:55:02,305 Command udi_interface.interface DEBUG interface:_parseInput: DEQUEING notices 2023-12-16 14:55:02,308 Command udi_interface.custom DEBUG custom:load: CUSTOM: load {'no_connect': 'Could not connect to EnvisaLink device. Please check the network and Custom Configuration Parameter values for the nodeserver.'} 2023-12-16 14:55:02,309 Command udi_interface.custom DEBUG custom:load: CUSTOM: -- checking no_connect / Could not connect to EnvisaLink device. Please check the network and Custom Configuration Parameter values for the nodeserver. 2023-12-16 14:55:32,130 MQTT udi_interface.interface DEBUG interface:_message: QUEUING incoming message shortPoll 2023-12-16 14:55:32,131 Command udi_interface.interface DEBUG interface:_parseInput: DEQUEING shortPoll 2023-12-16 14:55:32,133 Thread-54 udi_interface DEBUG evldscns:shortPoll: In shortPoll()... 2023-12-16 14:55:32,135 Thread-54 udi_interface INFO nodes:shortPoll: Establishing connection to EnvisaLink device... 2023-12-16 14:55:32,135 Thread-54 udi_interface DEBUG evltpi_dsc:_connect_evl: Connecting to EnvisaLink device... 2023-12-16 14:55:32,136 Thread-54 udi_interface DEBUG evltpi_dsc:_connect: In connect()... 2023-12-16 14:55:32,138 Thread-54 udi_interface DEBUG evltpi_dsc:_get_next_cmd_seq: In _get_next_cmd_seq()... 2023-12-16 14:55:32,139 Thread-54 udi_interface ERROR evltpi_dsc:_get_next_cmd_seq: TCP Connection to EnvisaLink unexpectedly closed. Socket error: [Errno 54] Connection reset by peer 2023-12-16 14:55:32,140 Thread-54 udi_interface ERROR evltpi_dsc:_connect_evl: Invalid sequence received from EnvisaLink upon connection: None 2023-12-16 14:55:32,142 Thread-54 udi_interface.node DEBUG node:setDriver: panel1:Alarm Panel Reporting set ST to 0 to Polyglot 2023-12-16 14:55:32,143 Thread-54 udi_interface.node DEBUG node:reportDriver: Updating value to 0 2023-12-16 14:55:32,143 Thread-54 udi_interface WARNING nodes:shortPoll: Could not connect to EnvisaLink device at 192.168.2.223. 2023-12-16 14:55:32,144 Thread-54 udi_interface.custom DEBUG custom:__setitem__: CUSTOM: no_connect = Could not connect to EnvisaLink device. Please check the network and Custom Configuration Parameter values for the nodeserver. ...saving 2023-12-16 14:55:32,145 Thread-54 udi_interface.custom INFO custom:_save: Sending data notices to Polyglot.

OK - I though you had the flow meter as well I believe this is the same API as the manipulator that is/was used to control valves before. The name of the node is what you specify in the YoLonk app (short of special characters) - the yomanipu is the manupulator driver. This shoudl work fine

My guess is it reports as 2 different devices - and one is the valve controller (manipulator). There is no API yet for the flow meter but hopefully it will come soon. Once it is available maybe you can give me access to your controller for 1/2 a day and I can likely add the support - I would buy my self, but they do not have my pipe diameter

Decided to make a new thread to add info on new releases rather than create anew one for each new release Info also exists in release notes 0.9.87 - Added more info for TH sensor alarms (and fixed bug). Improved node stare for multiOutput device if the device is off-line during start

you can get some functionality inside the ISY with Phyn using Alexa or IFTTT I have not seen the Yolink flow meter functionality, but I guess it does not offer the triggers for leak detection (yet) - it seems there is a lot of learning involved to understand if something is a leak or just normal water use. Otherwise you may get a lot of false triggers I have looked at buying the YoLink electronics for the flow meter by it self, but I have not found a compatible 1 1/4 flow meter yet (needs to read the 0.01 gallon meter/indicator) - can only find for - readers on the 0.1 galon meter/indicator

I only see 1 and 1 1/2 listed - can you send a link? Christian

The flow meter is new and I have not integrated it yet - Unfortunately they do not offer the pipe size I need 1 1/4 so I have not bought one yet. If someone could give me access I can try to integrate it - It could be set up with a separate account I could use to access it

Sorry - forgot to update version number - should be there now

Updated to 0.9.85 - found a minor bug causing the delay of calls to start too early Checked the code once more - shortPoll does not update deviced with calls to YoLink servers (so it should not add to calls) - only LongPoll does an update - set shortPoll back to 5min Still seeing unexplained supression by YoLink servers - waiting to hear back from them

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)