Jimbo.Automates

ELK PG3 NS Issues fixed and 3.4.2 released.

I found an issue with this version where arming and disarming from a program is not working, I will work on a fix today.

The Polyglot Version 3 Node server for ELK Security Version 3.4.7 is released. See the Release Notes Please make sure your Polisy is up to date by running Upgrade Packages in the Admin Console -> Configuration -> System section. See the README for more information, including information on moving from PG2. If you have issues or requests please check PG3 ELK Github issues to see it has already been listed. And if you want to thumbs up an issue I will try to prioritize fixing the ones with most votes.

All my batteries look fine. Must be a bad batch of batteries? Sent from my Pixel 6 Pro using Tapatalk

@Dub aka WHaas Sorry for my delayed response. Thanks for the Praise, very much appreciated. >> Is it expected behavior to not see a subject line when using Custom Notification from Polisy? I need to confirm this, it's not under my control, it's how the ISY processes it. If there is anything in the body then only the body is sent, otherwise it uses subject. I should add more info about that in the doc, but it's such a new feature in the ISY that it wasn't completely understood. >> Also, there may be a small typo on the PG3 NS config page that produces the same behavior as above, but for Network Resources. The parameter for the Subject line is capitalized in the example for the path, but changing it to lowercase seems to correct the issue and will send the custom subject line. This is when using Network Resources to send a request to the node server. Yes, I have noticed that before and keep forgetting to fix it... That info is generated on the fly by the code. @MrBill Thanks for providing your expertise. With the new options to send with parameters you don't have to worry as much about changing the defaults and changing them back, you can just call them for the one message: https://github.com/UniversalDevicesInc-PG3/udi-poly-notification#send-sys-short-with-params

Yes, I've stopped receiving the errors so seems to be all good.

Yes, seems to be all fixed now

Today I started receiving these errors from the PG3 CAO Wireless Tags URL calling: URL: Kitchen Freezer Probable I/O race condition detected while copying memory. The I/O package is not thread safe by default. In multithreaded applications, a stream must be accessed in a thread-safe way, such as a thread-safe wrapper returned by TextReader's or TextWriter's Synchronized methods. This also applies to classes like StreamWriter and StreamReader., URL attempted to call: http://192.168.86.88:10916/update?tmgr_mac=6B24C795B80E&name={0}&tagid={1}&temp={2}&hum={3}&lux={4}&ts={5}&batv={6}&signaldBm={7}&txpwr={8} I've submitted a support ticket and a forum post as well: https://groups.google.com/g/wireless-sensor-tags/c/oKybvgbx0j0 Is anyone else seeing these as well?

Yes it should work the same triggering scene from a program or UD Mobile, if not then check the Kasa NS log for errors. Sent from my Pixel 6 Pro using Tapatalk

Much easier with notification node server [emoji6] With the next release of PG3 there should be a basic free option and the paid pro option with more features. Sent from my Pixel 6 Pro using Tapatalk

ELK Node Server Users, can you thumb's up an issue you would like worked on? That will help me gauge the need and desire for them: https://github.com/UniversalDevicesInc-PG3/udi-poly-ELK/issues

PG3 ELK Node Server 3.3.8 Released see the Release Notes

The latest Polisy updates seem to have broken the ELK Node server. I will try to get a fix out soon.

The Polyglot Version 3 Ecobee Node server 3.1.2 is released to production. This version supports the new Ecobee thermostat with Air Quality Sensor. See the README for more information, including information on moving from PG2 The Release Notes are also available.

Yes, it's each device, not the sensors in the device. On each poll it gets current data for all sensors in the device, but if the value is the same as previous then PG3 doesn't pass it on to the ISY. Sent from my Pixel 6 Pro using Tapatalk

Issue updated: https://github.com/UniversalDevicesInc-PG3/udi-poly-Airthings-Consumer/issues/13 Also updated config doc: https://github.com/UniversalDevicesInc-PG3/udi-poly-Airthings-Consumer/blob/main/CONFIG.md

I do not have this specific device, but I do have a power strip which uses the same exact code. I was able to see this happen one time, but I can not make it happen again. I added more debug code to try and pin down why this is happening, so if you can update to 3.0.11, make sure the NS Log is in Debug mode, then see if you can make it happen again. You can download the log and send it to me in a PM again and say which Node name was showing the issue. What I think is happening is the node server says to turn off the plug, then poll's the main device, because it can't poll the individual plug, and for some reason it is reporting the plug is still on. I can add a delay in between, but that's not really a robust solution.

Sorry about that, fixed in 3.3.7. You'll just have to go set it back to true where desired. I had noticed this last night for the use off node as well.

PG3 ELK Node Server 3.3.7 Released see the Release Notes

PG3 ELK Node Server 3.3.6 Released see the Release Notes

Fixed in 3.3.6, thanks for reporting.

Looks like the rate limit issue as well: 2022-07-16 00:03:04,512 Thread-16889 udi_interface ERROR pgSession:response: Unknown response 429: https://ext-api.airthings.com/v1//devices/2930024519/latest-samples {"error":"TOO_MANY_REQUESTS","error_description":"Rate limit on API exceeded","error_code":1070} Added info to issue: https://github.com/UniversalDevicesInc-PG3/udi-poly-Airthings-Consumer/issues/13

Issue added: https://github.com/UniversalDevicesInc-PG3/udi-poly-Airthings-Consumer/issues/13

Issue added: https://github.com/UniversalDevicesInc-PG3/udi-poly-Airthings-Consumer/issues/12

Sorry, just saw this. I need to confirm what that time value is. Issue added: https://github.com/UniversalDevicesInc-PG3/udi-poly-Airthings-Consumer/issues/11 It only polls once for all devices, so it shouldn't blow the rate limit.