SamM

Thanks @sjenkins - I can confirm the latest updates on the non-production store do address both Raw and Temp mqtt device types. Much appreciated! -Sam

With the recent updates, I'm not seeing any value updates for my Temp and raw mqtt nodes. My current setup: PG3x Version 3.2.22 Frontend Version: 3.2.22 IoX Version: 5.8.3 MQTT Plugin Version: 0.0.39 - configured to the eisy mqtt broker, and using a devfile for my devices Looking through the other recent threads, I see the other reports for sonoff switches - so not sure if this is the same problem, or something separate. I do see the nodes being created in the Polyglot V3 page for the plugin, and I can observe the mqtt feed updating in MQTT Explorer, but no node values are being updated from the mqtt feed. Some information from my logs: DEBUG Controller:_get_device_address_from_sensor_id: DLT: [{'id': 'tempTurtleL', 'name': 'Turtle Left Temp', 'type': 'Temp', 'status_topic': 'sensor/1wire/28aab8a6161302c2', 'cmd_topic': 'sensor/1wire/28aab8a6161302c2', 'sensor_id': 'SINGLE_SENSOR', 'extra_status_topic': 'sensor/1wire/STATUS10'}, {'id': 'tempTurtleR', 'name': 'Turtle Right Temp', 'type': 'Temp', 'status_topic': 'sensor/1wire/28fe30701b13013f', 'cmd_topic': 'sensor/1wire/28fe30701b13013f', 'sensor_id': 'SINGLE_SENSOR', 'extra_status_topic': 'sensor/1wire/STATUS10'}, {'id': 'HAssStatus', 'name': 'HAss Status', 'type': 'raw', 'status_topic': 'homeassistant/status', 'cmd_topic': 'homeassistant/status'}] ... 2024-04-28 16:52:53,695 Thread-15 udi_interface DEBUG Controller:_get_device_address_from_sensor_id: NODE_ID2: None 2024-04-28 16:52:53,695 Thread-15 udi_interface DEBUG Controller:_get_device_address_from_sensor_id: NODE_ID2: None 2024-04-28 16:52:53,695 Thread-15 udi_interface DEBUG Controller:_get_device_address_from_sensor_id: NODE_ID2: None 2024-04-28 16:52:53,695 Thread-15 udi_interface ERROR Controller:_on_message: Failed to process message 'NoneType' object has no attribute 'updateInfo' 2024-04-28 16:52:53,695 Thread-15 udi_interface ERROR Controller:_on_message: Failed to process message 'NoneType' object has no attribute 'updateInfo' 2024-04-28 16:52:53,695 Thread-15 udi_interface ERROR Controller:_on_message: Failed to process message 'NoneType' object has no attribute 'updateInfo' Please let me know if there is more information that I can supply. Thanks, Sam

I updated my production node server on Friday after you merged the pull request. It has been working flawlessly since. Thanks again @bpwwer. -Sam

Thanks @bpwwer - I've created a fork with my changes, and started pull request https://github.com/UniversalDevicesInc-PG3/udi-presenceUnifi-nodeserver/pull/3. If you don't see any issues with it, please consider merging that in and updating the store as needed. Though I made a number of other changes to my dev version of the node server, I'm only pushing those necessary to address the issue at hand. As I see several things that could be improved going forward, I would be interested in taking over ownership if that is helpful. Thanks again, Sam

As I have found this nodeserver valuable in some of my programs, I've been investigating and testing a fix for this issue. However, it appears that I don't have permissions to create a branch and/or pull request to assist with pushing/reviewing a potential fix. Based on prior discussion, the original owner/maintainer is unable to continue maintenance of this nodeserver: From that discussion, @bpwwer had permissions to push a fix. Going forward, is there a better method for nodeservers who no longer have an active owner? Do we need somebody to take ownership in order to address issues and/or make general improvements as needed? With that being said, I've also been exploring some basic fixes that would/could make this nodeserver fit my needs even better. -Sam

Some more details while investigating the issue that I'm having with the UnifiPresence nodeserver... Unifi does not supply/support a python API into their controllers. Instead, members of the user community have created various modules to communicate with Unifi's web API. The modules are all very similar, including the fact that they are not regularly maintained, and make various assumptions that have worked okay to this point. Unfortunately, none appear to properly handle the 401 responses. UnifiPresence currently has the controller piece of this copied into its source: https://github.com/NickWaterton/Unifi-websocket-interface That module has not been updated in a few years. I have also investigated this module, since it has more recent updates (almost 2 years ago): https://github.com/finish06/pyunifi. Both solutions make use of a python requests session, with attempts to re-login when exceptions are detected. -Sam

My CK2-Plus recently updated to UniFi OS 3.2.7. Unfortunately it appears that Unifi has introduced an expiration to their authentication tokens, resulting in UnifiPresence resetting all presence nodes to 0. The only workaround that I've found so far is to manually restart the nodeserver every couple of hours. I'm curious if anybody else is experiencing this issue. And whether there is anybody available to help support this node server. Some notes... Setting the nodeserver logging level to DEBUG only yields this detail: 2023-12-24 08:07:03,205 Thread-1119 udi_interface.node DEBUG node:setDriver: 80b989304495:80b989304495 No change in GV1's value 2023-12-24 08:07:03,205 Thread-1119 udi_interface INFO unifi_poly:update: update: 0 Creating a simple python script to mimic the nodeserver behavior, I have confirmed that the underlying python module that communicates with the Unifi controller does not properly handle 401 authentication failures that now appear ~2 hours after the initial connection. It does do a brute force re-login process when certain connection exceptions are detected, but does not for this particular error condition: 2023-12-22 21:41:05,586 [WARNING] [pyunifi.controller] Received response 401 (Unauthorized) 2023-12-22 21:41:05,586 [WARNING] [pyunifi.controller] Failed to perform <function Controller._read at 0x1060760e0> due to Received response 401 (Unauthorized) Since the python requests module can be configured to throw an exception when error responses like this are detected, the fix can be fairly simple. However, I'm not currently set up to install and confirm nodeserver changes with PG3. -Sam

Thanks @bmercier - followed the suggested steps and my node servers are now connected. One note, on my system, the pip install of the aioquic resulted in more than warnings. I actually ended up with a number of errors while building wheel for aioquic. However, pyOpenSSL did update to 23.2.0 as expected. -Sam

It looks like I'm in the same situation with all node servers showing disconnected status after the most recent update. While it appears most of the other reports are 3.2.1/2 -> 3.2.3, I actually updated from 3.1.36 -> 3.2.3 (and IoX 5.6.3 -> 5.6.4). As instructed, I've re-installed all node servers. And have attempted a few reboots (both from the admin console UI and power cycling my eISY). I've submitted a ticket with PG3x logs after performing my most recent reboot. -Sam

I'm running polyglot in a container on my NAS, and had been mentally converting UTC to PST since installing. This comment prompted me to correct this for my configuration. The following allowed me to correct my TZ: > dpkg-reconfigure tzdata From there, I was able to select America/Los_Angeles. And now my dates are displayed correctly: root@polyglot:/home/pi/.polyglot/nodeservers/Ecobee/logs# date Wed Jan 23 07:05:53 PST 2019 root@polyglot:/home/pi/.polyglot/nodeservers/Ecobee/logs# tail debug.log 2019-01-23 07:03:10,296 [Controller] [DEBUG] rs_qr4k:update: updates={'GV1': 0, 'ST': 75.0} 2019-01-23 07:03:10,296 [Controller] [INFO ] Updating Driver rs_qr4k - ST: 75.0, uom: 17 2019-01-23 07:03:10,297 [Controller] [DEBUG] rs_cclt:update: 2019-01-23 07:03:10,297 [Controller] [DEBUG] rs_cclt:update: sensor={'inUse': True, 'code': 'CCLT', 'name': 'Stairwell', 'capability': [{'id': '1', 'type': 'temperature', 'value': '679'}, {'id': '2', 'typ e': 'occupancy', 'value': 'true'}], 'id': 'rs:102', 'type': 'ecobee3_remote_sensor'} 2019-01-23 07:03:10,298 [Controller] [DEBUG] rs_cclt:update: updates={'GV1': 1, 'ST': 67.9} 2019-01-23 07:03:10,298 [Controller] [INFO ] Updating Driver rs_cclt - ST: 67.9, uom: 17 2019-01-23 07:03:10,299 [Controller] [DEBUG] s411958194987:update: 2019-01-23 07:03:10,299 [Controller] [DEBUG] s411958194987:update: sensor={'inUse': True, 'id': 'ei:0', 'type': 'thermostat', 'name': 'GreenTreeBee', 'capability': [{'id': '1', 'type': 'temperature', 'val ue': '706'}, {'id': '2', 'type': 'humidity', 'value': '47'}]} 2019-01-23 07:03:10,300 [Controller] [DEBUG] s411958194987:update: updates={'CLIHUM': '47', 'GV1': 2, 'ST': 70.6} 2019-01-23 07:03:10,300 [Controller] [INFO ] Updating Driver s411958194987 - ST: 70.6, uom: 17