See the README and Release Notes

I've resolved all current issues that I plan to work on, or can fix are done.  if you have an issue that is not listed please add it, or let me know.

Whenever I restart IoX both my active Airthings-C plug-ins restart. For one of them it causes the plug-in to exceed the API limit for multiple update cycles that can last up to 45 mins when I look back to previous restarts.

The plug-in that violates the API contract supports 9 devices with short poll of 330 (5 1/2 mins), which is sufficient in terms of not exceeding API limit (anything over 270 is enough) unless a plug-in restart occurs. The other active plug-in doesn't hit the API limit but it only has 4 devices and a 200 sec short poll.

Unfortunately, for several reasons I need to restart IoX with some regularity, meaning a regular violation of the API contract with Airthings. Ideally could you put in a delay of short poll duration at plug-in restart to ensure there is no API limit violation? Desirable would also be no automatic restart when one is just calling for an IoX restart. That seems like a bug to me but I see other plug-ins restart too so maybe there's a reason for it that I'm not seeing? I guess it's not a big deal if one doesn't have an API call limitation but is more problematic when there is one.

I will PM you my log (set to Info) for today. There was an automated restart just before 2AM and a manual one around 8:12 AM. Let me know if you need a lower level of debug logs. It's easy to change and replicate the issue.

Here's a screenshot showing how PG3 has been running for a couple of weeks now while the plug-in has only been running for less than an hour (when I took the screenshot).

Note that this has been happening for a while. i just haven't taken the time to report it until now. 

Thanks

Would it be possible to add the PM 1.0 and 2.5 measurements to the nodeserver? 

Are there hidden parameters to hide some of the devices

Just installed - I have 2 sensors (in different locations) 

I try to set the short Poll to more than 60 (say 120) - but when I restart the node it resets to 60 and stops

Also - note there is a warning that PM1 ad PM2.5 is missing

Installed the trial version - I have 2 AirThings sensors so I am supposed to set the poll rate to more than 60 sec - however when I do so after restart it reverts to 60 sec and complains - is this a bug

Also, I noticed the particle count is not reported 

2024-09-22 13:24:04.648 Thread-107 (handler_poll) udi_interface      ERROR    pgSession:response: Not Found: https://ext-api.airthings.com/v1//devices/3220001054/latest-samples: text: {"error":"NOT_FOUND","error_description":"segment for user <myapikey> does not exist"}
2024-09-22 13:24:04.648 Thread-107 (handler_poll) udi_interface      ERROR    Controller:api_get: failed to parse res={'code': 404, 'data': {'error': 'NOT_FOUND', 'error_description': 'segment for user <myapikey> does not exist'}}
Traceback (most recent call last):
  File "/var/polyglot/pg3/ns/<myeisy>_8/nodes/Controller.py", line 251, in api_get
    LOGGER.warning(f"Service returned code {code} {res['data']['message']}")
                                                   ~~~~~~~~~~~^^^^^^^^^^^

This caused the "server status" in IoX to become false and it triggered a program to notify me of that every short poll. I didn't notice until I checked my email later to see an inbox full of notifications. It's like the polling temporarily changes the status to something other than false but then back to false, causing the program to trigger each time. IMO, I should have only received one notification when it went false the first time.

The problem stopped after I restarted the plug-in but I'd suggest that, if possible, some cleaning up could be done within the plug-in when one deletes a node so one does not have to restart to avoid this error. Alternatively the plug-in could restart itself (if that's possible) or a message to restart the plug-in could be provided, although these are less elegant solutions. The problem with restarts is that they reset the polling timer to zero, which causes the API limit to be reached.

Of course this is not critical. Just something to maybe consider the next time the plug-in is opened up for changes.

Thanks for all the good work you've done on this plug-in to make using these devices in my automation possible.

2.  This one is new.  I can post a video or send you one PM if you cant reproduce but after I update from 1.2.2 to 1.2.3 it shows 1.2.3 for about 5 seconds and then goes back to 1.2.3   The UPDATE button stays there so it thinks it needs an update but no update blue banner.  I can also send a log package if you want

Part of my reason for setting it longer is that it helps prevent hitting API rate limit for those times when I have to restart the plug-in or reboot. (I have 8 devices.) While this isn't a daily thing, of course, it often comes in clumps with more than one restart, which ends up blowing the limit. With this in mind, in addition to letting people be able to set their own short poll, could the plug-in save a timestamp of the last time it did a poll such that it lives through restarts?

2024-07-16 03:02:30.244 Thread-867 (handler_poll) udi_interface      ERROR    Controller:_query_all: Previous query still running
2024-07-16 03:02:30.244 Thread-867 (handler_poll) udi_interface      INFO     Controller:shortPoll: exit
2024-07-16 03:07:00.248 Thread-869 (handler_poll) udi_interface      INFO     Controller:shortPoll: enter
2024-07-16 03:07:00.248 Thread-869 (handler_poll) udi_interface      INFO     Controller:_query_all: enter
2024-07-16 03:07:00.248 Thread-869 (handler_poll) udi_interface      ERROR    Controller:_query_all: Previous query still running
2024-07-16 03:07:00.248 Thread-869 (handler_poll) udi_interface      INFO     Controller:shortPoll: exit
2024-07-16 03:11:30.249 Thread-870 (handler_poll) udi_interface      INFO     Controller:shortPoll: enter
2024-07-16 03:11:30.249 Thread-870 (handler_poll) udi_interface      INFO     Controller:_query_all: enter
2024-07-16 03:11:30.250 Thread-870 (handler_poll) udi_interface      ERROR    Controller:_query_all: Previous query still running
2024-07-16 03:11:30.250 Thread-870 (handler_poll) udi_interface      INFO     Controller:shortPoll: exit
2024-07-16 03:16:00.259 Thread-872 (handler_poll) udi_interface      INFO     Controller:shortPoll: enter
2024-07-16 03:16:00.259 Thread-872 (handler_poll) udi_interface      INFO     Controller:_query_all: enter
 

While there appears to have been an update made around 2AM early this morning, the log before and after that update is just full of the above messages

I did make some tweaks yesterday that included changing short poll time and doing a restart. This did result in reaching the API limit but only once, which I blamed on the restart causing some short shifting. Maybe, though, reaching the API limit (even only once) caused the problem? I've had API limit messages in the past but things always sorted themselves out assuming short poll is reasonable (I always set it above 30 X number of devices).

A restart of the plug-in did fix the problem - at least for now. 

Airthings-C_7-16-2024_113452_AM.zip

1. wait a bit. didn't do anything

2. restart each plug-in. nothing

3. re-launched IoX GUI - no joy

4. rebooted hardware - 2 of the three plug-ins now show the new data in IoX

What is/are the step(s) needed after a re-install to get new info activated/passed on to IoX?

If that fails, what is the step to force updates to be recognized and passed on to IoX?

Am on PG3x 3.2.22 and IoX 5.8.3.

Thanks

After reboot of EISY (twice so far) I get the message after a while that 60 is too low for 5 devices.  So I raise to 120 or more (I put 150)

All is fine until I reboot and then its back to 60.

Things like:

2024-05-28 05:29:04,383 Thread-700 urllib3.connectionpool WARNING  connectionpool:urlopen: Retrying (Retry(total=18, connect=30, read=28, redirect=None, status=None)) after connection broken by 'ReadTimeoutError("HTTPSConnectionPool(host='ext-api.airthings.com', port=443): Read timed out. (read timeout=10)")': /v1//devices/2930162741/latest-samples

2024-05-28 05:29:05,365 Thread-697 urllib3.connectionpool WARNING  connectionpool:_put_conn: Connection pool is full, discarding connection: ext-api.airthings.com. Connection pool size: 10

2024-05-28 05:18:40,345 Thread-666 udi_interface      ERROR    pgSession:get: Connection error for https://ext-api.airthings.com/v1//devices/2930162741/latest-samples: HTTPSConnectionPool(host='ext-api.airthings.com', port=443): Max retries exceeded with url: /v1//devices/2930162741/latest-samples (Caused by ResponseError('too many 502 error responses'))

2024-05-28 05:28:04,528 Thread-547 udi_interface      ERROR    pgSession:response: Unauthorized: https://ext-api.airthings.com/v1//devices/2930162814/latest-samples: text:

I didn't see anything about API limit reached so it seems to be an erroneous state got reported to IoX (which triggered an email to warn me). Maybe the flood of warnings lead to that? Would it be a good idea to put in a "wait" between retries to avoid possible race conditions, or at least reduce the clutter in the logs? (Unless there's value in having all of those entries.)

Maybe there was a short break in service that affected 2 of the instances but not the third due to polling difference. The 3rd one did have a few warnings but maybe the break in service ended shortly after first few

I've attached my 3 debug logs (one was only set to "Warning" level. I've changed it to "Info" for next time)

Airthings-C_5-28-2024_62253_AM.zip Airthings-C_5-28-2024_62237_AM.zip Airthings-C_5-28-2024_61905_AM.zip

My perpetual license is not recognized meaning I would have to purchase another one to install v1.1.1. Is that the plan or do I need to talk to UDI support to get the new version to recognize my existing license? I did need to have the license transferred from my Polisy some time ago so maybe that has something to do with it?

The third instance doesn't show any unhandled errors but was full of these:

2024-01-07 00:05:11,717 Thread-2696 udi_interface      WARNING  Sensor:query: Unknown param virusRisk=7.0

It's strange to me that the above would be occurring for one but not the others. All instances are monitoring Wave Plus devices so technically it seems to me if it's reported for one, it should be reported for all. That said, I don't think Wave Plus devices provide a "risk" value. I believe that's a feature of the Wave Mini, not the Wave Plus, so it shouldn't be looking for this parameter at all.

Attached are:

1. the unhandled errors (downloaded today combined into one file) for NS instances in slot 1 and and slot 9
2. today's log for the instance in slot 8 showing all the instances so far today of the above message
3. a screenshot showing example of the UD notifications I get periodically. It can happen a few days in a row then not at all for several days

The good news is that my ISY nodes are still being updated so the errors appear to be relatively benign and/or self healing.

AT-unhandled errors.txt AT-unknown param.txt

Was wondering if you could add missing fields to the plugin.  Looking specifically for VOC values, the VOCLVL just indicates whether it is Clean not the actual value.  I have attached screenshots to show what IOX provides vs the Node listings.

I record my readings in an ISY web file (e.g. @webpage:@append:mydir/VOCdata.htm) and use excel to analyze my data, and I'm considering something more sophisticated using PowerBI or InfluxDB. The only thing that remains unique over time for some of my devices is the device serial number because I move them around and rename them to something representing the location they are in at that time. I need both a consistant unique identifier and a meaningful short name as separate data fields.

Thanks for considering it.

I'm wondering if there's any plans for an update to this NS. I think it's been over a year since the last major update https://forum.universal-devices.com/topic/39323-pg3-airthings-consumer-node-server-101/

Also, I see there are 6 official "open" issues going back to July 2022 https://github.com/UniversalDevicesInc-PG3/udi-poly-Airthings-Consumer/issues

plus there a couple of recent feature requests:

And possibly some bugs (TBD as of this posting)

Thanks for considering it.

About 99% of my google search results for the formula or algorithm to convert current time to unix epoch time were either online calculators for human consumption, how to do it in Excel, or talked about using built in linux or windows commands, e.g. date +%s  in linux. (I tested the latter and it does work on the Polisy.) When I did find formula or algorithm info it was shell code or python, etc., which didn't translate well to ISY programming and made me think it was silly to try to do it using ISY programming. 

Instead I wondered if you could make the NS do the simple calculation of subtracting 'date +%s' from epoch time that the API provides (both have same 10 digit resolution) and display a "time since last updated" in minutes or seconds. As far as I'm concerned it could replace the current time field in NS/ISY because I can't see what other use the unix epoch time would have but if you wanted to have both, it's fine with me.

Thanks for considering it.

2023-08-17 19:28:59,098 Thread-1076 udi_interface.interface ERROR    interface:send: MQTT Publish Error: [SSL: BAD_LENGTH] bad length (_ssl.c:2488)
Traceback (most recent call last):
  File "/var/polyglot/.local/lib/python3.9/site-packages/udi_interface/interface.py", line 632, in send
    self._mqttc.publish(topic, json.dumps(message), retain=False)
  File "/var/polyglot/.local/lib/python3.9/site-packages/paho/mqtt/client.py", line 1257, in publish
    rc = self._send_publish(
  File "/var/polyglot/.local/lib/python3.9/site-packages/paho/mqtt/client.py", line 2693, in _send_publish
    return self._packet_queue(PUBLISH, packet, mid, qos, info)
  File "/var/polyglot/.local/lib/python3.9/site-packages/paho/mqtt/client.py", line 3016, in _packet_queue
    return self.loop_write()
  File "/var/polyglot/.local/lib/python3.9/site-packages/paho/mqtt/client.py", line 1577, in loop_write
    rc = self._packet_write()
  File "/var/polyglot/.local/lib/python3.9/site-packages/paho/mqtt/client.py", line 2464, in _packet_write
    write_length = self._sock_send(
  File "/var/polyglot/.local/lib/python3.9/site-packages/paho/mqtt/client.py", line 649, in _sock_send
    return self._sock.send(buf)
  File "/usr/local/lib/python3.9/ssl.py", line 1174, in send
    return self._sslobj.write(data)
ssl.SSLError: [SSL: BAD_LENGTH] bad length (_ssl.c:2488)
2023-08-17 19:28:59,099 MQTT       udi_interface.interface INFO     interface:_disconnect: MQTT Unexpected disconnection. Trying to reconnect in 10 seconds. rc: 7

The two other instances did not report this or any other any issues around that time.

Am on PG3 3.1.21 and IoX 5.6.4 on Polisy.

Yes, I have the NS configured with change_node_name set to true

For example, I dropped an apostrophe for 2 devices in the AT Dashboard but the apostrophe remains in NS and ISY.

Is that because we're talking about an apostrophe, i.e. a special character? I didn't test that theory but think this should be fixed anyway so figured I would report it. That or a clear warning should be put in a highly visible spot that warns against the use of any problematic characters if that's the case to give people a chance to rename any offending device before they start the NS.

I set a program that if Radon levels get high to let me know via alexa.  They did but in a couple hours it came right down.

The RADON company said ask your home automation guy if you can monitor the 2 day average and not the current reading.  They told me (And you can see in the app) that airthings supports that.

Can we get that reading into the ISY?

2022-11-17 01:48:36,971 Thread-693 udi_interface      ERROR    udi_interface:write: Exception in thread
2022-11-17 01:48:36,973 Thread-693 udi_interface      ERROR    udi_interface:write: Thread-693
2022-11-17 01:48:36,973 Thread-693 udi_interface      ERROR    udi_interface:write: :
2022-11-17 01:48:36,974 Thread-693 udi_interface      ERROR    udi_interface:write: Traceback (most recent call last):
2022-11-17 01:48:36,975 Thread-693 udi_interface      ERROR    udi_interface:write: File "/usr/local/lib/python3.9/threading.py", line 980, in _bootstrap_inner
2022-11-17 01:48:36,979 Thread-693 udi_interface      ERROR    udi_interface:write: self.run()
2022-11-17 01:48:36,980 Thread-693 udi_interface      ERROR    udi_interface:write: File "/usr/local/lib/python3.9/threading.py", line 917, in run
2022-11-17 01:48:36,983 Thread-693 udi_interface      ERROR    udi_interface:write: self._target(*self._args, **self._kwargs)
2022-11-17 01:48:36,984 Thread-693 udi_interface      ERROR    udi_interface:write: File "/var/polyglot/pg3/ns/<my ISY ID>_8/nodes/Controller.py", line 149, in handler_poll
2022-11-17 01:48:36,986 Thread-693 udi_interface      ERROR    udi_interface:write: self.shortPoll()
2022-11-17 01:48:36,987 Thread-693 udi_interface      ERROR    udi_interface:write: File "/var/polyglot/pg3/ns/<my ISY ID>_8/nodes/Controller.py", line 153, in shortPoll
2022-11-17 01:48:36,988 Thread-693 udi_interface      ERROR    udi_interface:write: self._query_all()
2022-11-17 01:48:36,989 Thread-693 udi_interface      ERROR    udi_interface:write: File "/var/polyglot/pg3/ns/<my ISY ID>_8/nodes/Controller.py", line 183, in _query_all
2022-11-17 01:48:36,990 Thread-693 udi_interface      ERROR    udi_interface:write: node.shortPoll()
2022-11-17 01:48:36,991 Thread-693 udi_interface      ERROR    udi_interface:write: File "/var/polyglot/pg3/ns/<my ISY ID>_8/nodes/Sensor.py", line 104, in shortPoll
2022-11-17 01:48:36,993 Thread-693 udi_interface      ERROR    udi_interface:write: self.query(force=False,authorize=False)
2022-11-17 01:48:36,993 Thread-693 udi_interface      ERROR    udi_interface:write: File "/var/polyglot/pg3/ns/<my ISY ID>_8/nodes/Sensor.py", line 113, in query
2022-11-17 01:48:36,995 Thread-693 udi_interface      ERROR    udi_interface:write: st = self.controller.api_get(f"devices/{self.serial}/latest-samples")
2022-11-17 01:48:36,996 Thread-693 udi_interface      ERROR    udi_interface:write: File "/var/polyglot/pg3/ns/<my ISY ID>_8/nodes/Controller.py", line 202, in api_get
2022-11-17 01:48:36,997 Thread-693 udi_interface      ERROR    udi_interface:write: res = self.session.get(
2022-11-17 01:48:36,998 Thread-693 udi_interface      ERROR    udi_interface:write: File "/var/polyglot/pg3/ns/<my ISY ID>_8/pgSession.py", line 65, in get
2022-11-17 01:48:37,000 Thread-693 udi_interface      ERROR    udi_interface:write: return(self.response(response,'get'))
2022-11-17 01:48:37,000 Thread-693 udi_interface      ERROR    udi_interface:write: File "/var/polyglot/pg3/ns/<my ISY ID>_8/pgSession.py", line 88, in response
2022-11-17 01:48:37,002 Thread-693 udi_interface      ERROR    udi_interface:write: self.logger.error("Forbidden: %s: text: %s" % (response.url,json_data['message']) )
2022-11-17 01:48:37,002 Thread-693 udi_interface      ERROR    udi_interface:write: KeyError
2022-11-17 01:48:37,003 Thread-693 udi_interface      ERROR    udi_interface:write: :
2022-11-17 01:48:37,004 Thread-693 udi_interface      ERROR    udi_interface:write: 'message'

The node value that I noticed not getting updated was GV4 for device s_2930027997. There may be others too - I didn't go fishing for others.

A restart of the NS seems to have fixed things for now.

Attached is log for today, including entries after the restart. If needed I could SSH into Polisy to pull out older log files. Let me know if that would help at all.

Thanks.