vspete

@sjenkins, Version 1.12.3 of the plug-in is working fine accross the board (at the level supported by the G2 API). While a G3 hub might be better, I cannot justify replacing the G2 given my use case. I have tested all of the scenes and they are working fine. I will address some of your comments above from what I have observed. 1. For the G2, "default room" is only used as the "room descriptor" for scenes involving shades in multiple rooms. In IoX I place the shades and scenes in separate folders and rename them for clarity. All the scenes work as expected. The "Activated" field shows "True" while the shades are in motion and then returns to "False" 2. For me, using defined scenes gets the job done with a minimum of commands. I seldom position the shades manually. If I need to know their current status, I could make decisions using the shade's "Primary" value. 3. As I only use scenes to set the shades and "Activated" works like "Motion" there isn't any issue. All my shades are hardwired for power, so "Battery" always reports "High" Anyone installing and automating these shades today would undoubtedly use a G3 hub, so I wouldn't bother with creating separate G2 & G3 versions. 4. You do suggest shortening the polling rate in the config instructions. I set the Long Poll at 40 seconds as it takes about 35 seconds for my longest shade to go from open to closed. 5. Having the ability to "Set Shade Position" is a nice feature of the plug-in (works great). Don't know what "Set Shade Position: False" is for? Stephen, thanks again for the great plug-in and your steller support. Let me know if I can be of assistance should you wish to test any additional changes for G2 hub impact.

@sjenkins I think you have fixed all errors. Everything works and log is clean of errors. The plug-in is quite usable now for G2 hubs. Here are a couple of observations so far: 1. Multi-Room scenes receive the name "default room" 2. When a scene is activated, the activation parameter shows "True" briefly (one or two seconds) and than returns to "False" making it marginally usable. 3. Individual shade "Motion" remains "False" regardless of whether the shade is in motion. 4. "Primary" for a Bottom Up capable shade reports 0-100 with 100 being fully open and 0 being fully closed. This seems to update on the long Poll. To be useful, I will shorten the poll time closer to the time it takes to actually close a shade. 5. I tested "set shade position" function and it seems to work perfectly. Thanks again for working on my G2 hub issues. Best/Pete

@sjenkins, Installed the "beta" from the non-production store. This time NO NODES were populated in the plug-in nor created in the Admin Panel of the eISY. The polling errors remain as well. Please se the attached log. Thanks... HunterDouglas_9-24-2024_102709_AM.zip

The attached file contains the current url response from my hub. Thanks again for looking into this. Powerview 9-23-24.txt

I used these url's back in 2021 when I programmed the Network Resources (using GET method) on my ISY to activate the scenes I needed. Hre are the list of IDs: Scene IDs: 46541 - Back Close 3024 - All Open 50762 - Front Close 46928 - Front Open 1496 - DiningRm Afternoon 22300 - LivingRm Close 1604 - Dinner Close 27025 - Theater Close 59315 - LivingRm Front Close 41272 - LivingRm Back Close Room IDs: 51882 - Living Room 22692 - Kitchen 41649 - Dining Room 14194 - All Rooms Shade IDs: 11630 - Kitchen 53439 - Dining Room 53098 - Living Room Rear 10015 - Living Room Front I can reinstall the plug-in and capture the logs if that would help you. While the Network Resource method works, it does throw an error which needs to be ignored. I have yet to contact UDI to see if there is a way to keep errors from being reported in UD Mobile. Thanks again for your kind offer to work on the plug-in. Best / Pete

Thanks for the speedy reply. I didn't get notified of your post which is why this response is so late. I cleaned up the empty rooms leaving me with 3 "real rooms" and a "default" room where the multi-room scenes are registered. I also removed a couple of seldom used scenes using the app. Once this was complete, I removed the plug-in and reinstalled to a different slot. Unfortunately, when the plug-in "discovered" the rooms and shades, it created nodes for the scenes that I had previously deleted. The logs show the same scene errors as before. I expect that troubleshooting this will be a challenge. I have some other ways (using network resources and web "get" commands), to control the shades from the eISY, so for now I think I will use that method. I had used the hunter douglas apple homekit integration prior to trying the PG3x plug-in. I expect that is where the shadeless rooms came from. I removed that integration prior to the testing described above, but things may be cached somewhere and not cleared (despite an accurate home showing in the hunter douglas app). Thanks again for your help. If I learn anything of interest, I will report it here. Best/Pete

Just installed the plug-in (1.12.2). After startup completed, the eISY was correctly populated with my shades and scenes. However, no status or controls are available in admin console. the PGx plug-in log shows the following errors : 2024-09-15 10:50:09.585 Thread-2707 (poll) udi_interface INFO Controller:getHomeG2: getHomeG2 gateway good 192.168.46.37, ['192.168.46.37'] 2024-09-15 10:50:09.667 Thread-2707 (poll) udi_interface INFO Controller:updateAllFromServerG2: rooms = [35548, 14454, 18230, 51882, 4711, 5942, 22692, 41649, 39979, 14194, 40449, 59435, 54655, 34988] 2024-09-15 10:50:09.762 Thread-2707 (poll) udi_interface INFO Controller:updateAllFromServerG2: shades = [53098, 10015, 53439, 13409] 2024-09-15 10:50:09.851 Thread-2707 (poll) udi_interface INFO Controller:updateAllFromServerG2: [59315, 46541, 3024, 46928, 50762, 41272, 1496, 22300, 1604, 27025] 2024-09-15 10:50:09.851 Thread-2707 (poll) udi_interface INFO Controller:updateAllFromServerG2: updateAllfromServerG2 = OK 2024-09-15 10:50:09.851 Thread-2707 (poll) udi_interface INFO Controller:poll: event(total) = [{'evt': 'home', 'shades': [53098, 10015, 53439, 13409], 'scenes': [59315, 46541, 3024, 46928, 50762, 41272, 1496, 22300, 1604, 27025]}] 2024-09-15 10:50:19.465 Thread-2738 (poll) udi_interface INFO Shade:events: shortPoll shade 53098 update 2024-09-15 10:50:19.465 Thread-2739 (poll) udi_interface INFO Shade:events: shortPoll shade 10015 update 2024-09-15 10:50:19.465 Thread-2740 (poll) udi_interface INFO Shade:events: shortPoll shade 53439 update 2024-09-15 10:50:19.465 Thread-2741 (poll) udi_interface INFO Shade:events: shortPoll shade 13409 update 2024-09-15 10:50:19.465 Thread-2742 (poll) udi_interface INFO Scene:events: shortPoll scene 59315 update 2024-09-15 10:50:19.465 Thread-2743 (poll) udi_interface INFO Scene:events: shortPoll scene 46541 update 2024-09-15 10:50:19.465 Thread-2744 (poll) udi_interface INFO Scene:events: shortPoll scene 3024 update 2024-09-15 10:50:19.466 Thread-2745 (poll) udi_interface INFO Scene:events: shortPoll scene 46928 update 2024-09-15 10:50:19.466 Thread-2746 (poll) udi_interface INFO Scene:events: shortPoll scene 50762 update 2024-09-15 10:50:19.466 Thread-2747 (poll) udi_interface INFO Scene:events: shortPoll scene 41272 update 2024-09-15 10:50:19.466 Thread-2748 (poll) udi_interface INFO Scene:events: shortPoll scene 1496 update 2024-09-15 10:50:19.466 Thread-2749 (poll) udi_interface INFO Scene:events: shortPoll scene 22300 update 2024-09-15 10:50:19.466 Thread-2750 (poll) udi_interface INFO Scene:events: shortPoll scene 1604 update 2024-09-15 10:50:19.466 Thread-2751 (poll) udi_interface INFO Scene:events: shortPoll scene 27025 update 2024-09-15 10:50:19.467 Thread-2742 (poll) udi_interface ERROR Scene:events: scene event error sid = 59315 2024-09-15 10:50:19.467 Thread-2743 (poll) udi_interface ERROR Scene:events: scene event error sid = 46541 2024-09-15 10:50:19.467 Thread-2744 (poll) udi_interface ERROR Scene:events: scene event error sid = 3024 2024-09-15 10:50:19.467 Thread-2745 (poll) udi_interface ERROR Scene:events: scene event error sid = 46928 2024-09-15 10:50:19.467 Thread-2746 (poll) udi_interface ERROR Scene:events: scene event error sid = 50762 2024-09-15 10:50:19.468 Thread-2747 (poll) udi_interface ERROR Scene:events: scene event error sid = 41272 2024-09-15 10:50:19.468 Thread-2748 (poll) udi_interface ERROR Scene:events: scene event error sid = 1496 2024-09-15 10:50:19.468 Thread-2749 (poll) udi_interface ERROR Scene:events: scene event error sid = 22300 2024-09-15 10:50:19.468 Thread-2750 (poll) udi_interface ERROR Scene:events: scene event error sid = 1604 2024-09-15 10:50:19.468 Thread-2751 (poll) udi_interface ERROR Scene:events: scene event error sid = 27025 This sequence repeats at every shortpoll interval. Any help would be greatly appreciated.

Performed the reinstall as directed. Version shows to be "Free" and License shows to be "Perpetuall". After reinstall, I restarted the plug-in. After running for 60 seconds, the plug-in disconnects and reports an expired license as it has done since this issue started. After reading Gary's post I did it again (this time refreshing the store). This allowed me to choose a "Standard" rather than "Free" version to re-install. This did the trick and the plug-in is now running correctly. Thanks....

I have opened ticket #25032 Thank you, Pete

Hi Jim, thanks for the response. Good to know who works licensing issues. This is the first issue with licensing I have encountered. Will be nice to get your NodeServer back. Cheers!

I just restarted the Flumewater NodeServer with a perpetual license and now receive the "subscription for this node server has expired" message. The nodeserver has been running flawlessly for months. I am on an a eISY running PG3X v3.2.27 / IoX v5.8.4. Hopefully, JimBo can remedy this situation.

I am pleased to report that so far everything is working perfectly with "SmartZonetracking" enabled. Clearly, based on the offending message, "malformed" is the correct term for this message. What I find interesting is that while the malformed messages are frequent and identical, they do not occur every time a particular set of sensors are triggered or opened individually. What I have observed below seems always to be true: The panel is in a disarmed state An Exit Zone is Open A perimeter zone is open (or opened) AND one (or two) motion detectors are open (simultaneously). What I am not sure of (in addition to the ambiguity described in #3) is whether the malformed message is created during, after, or concurrent with the expiration of the entry delay initiated by opening the Exit Zone. In a disarmed state, the entry delay doesn't mean anything, but I don't know whether it might affect EnvisaLink messaging. I am going to mark this issue as solved. Thanks so much Randy for the effort you have put into addressing this issue.

Thanks for releasing the update. I will install and advise after a few days. Whether the offending data message is "malformed" or "undocumented", ignoring it would seem to be the appropriate solution. I was able to suppress these messages by changing zone #10's type to "interior type". Zone #10 is a perimeter (interior house to garage door) zone physically located between two interior motion zones. This change negatively affects my "stay" security but doesn't adversely affect "away." I will revert #10's zone type to a "perimeter," test the plugin and let you know.

I re-installed the node server to update to 2.1.2. The node server added two additional nodes named inside and outside linked to local_107 and local_60 respectively. I performed and "add all nodes" in IoX and the two new nodes were created in IoX. These new nodes were not populating correctly and I decided things were not updating correctly, so I decided it was getting too difficult to troubleshoot. The best path forward seemed to be to start with a clean install. I deleted the node server from PG3x and installed the node server into a different slot (just to be safe). I only specified the local IP addresses and restarted both the node server and IoX. The Local_60 sensor populated its screen, however, Local_107 did not populate correctly (many fields were blank and others were just wrong). I had started the ISY event monitor and have included the slot 5 results in the archive. The included debug log is for the clean re-install. After collecting the attached log information, I added the API key and returned the sensors to their API addresses and the node server is now reporting complete and accurate information. PurpleAir_2-24-2024_101913_AM.zip

I did take a look at the logs, but couldn't discern why certain values were not populating. I decided the best thing to do was do a complete re-install. I removed the node server completely from PG3x and then reinstalled. After restarting the node server and restarting IoX, all fields are now populated for both measurements and forecasts. Only "Climate Coverage" is "blank" in IoX for both Aeris Weather and Forecasts. The GV 11 (Weather) and GV11 (Forecasts) node values are "16" which matches to "blank" in the en_us.txt profile lookup table. It looks like it may be working as expected now. Now that all the fields are populated, I expect they will be updated when changes occur. Thanks for your assistance getting this resolved.

Good advice, thanks Bob. I will review those logs for errors and go from there. As stated previously, I never experienced this issue using the PG2 version of your node server running in a Debian Polyglot v2 VM communicating with a ISY994. This issue has to be an IoX/PG3x thing. I appreciate the time you have taken to answer my questions and confirm that it isn't a node server issue.

Bob, I can see that it is "publishing." However, IoX is not displaying what is "published." Perhaps this is not a node server issue per se. But it is definitely an issue. Aeris Weather is clearly displaying all the data on their site: https://www.pwsweather.com/station/pws/DW3801 The screenshots are what my eISY (IoX) screens looks like. If it isn't a node server issue, it must be an IoX or PG3x issue. Should I raise a trouble ticket with UDI? Thanks again Bob!

Bob, I appreciate that only changes are written. However, after several days certain fields have yet to be populated despite the numerous condition changes that have occurred. Those that are being populated are accurate. Here is the list of non-populating fields: Current weather: Gust Speed; Climate Coverage; Windchill; Precipitation Forecasts: Gust Speed; Precipitation; Chance of Rain; Evapotranspiration During that past few days we have had storms pass through with considerable wind and precipitation. One would expect these values to change. I am also running the Davis Node Server and it is populating all fields without issue. A can also report that this issue was not present when I was running the pg2 versiton of this node server on a different platform. Thanks...

Good morning @bpwwer, attached is the log file from this morning. I have observed that despite restarting IoX and the node server, configuration values are not completely reset to new values. The node server and IoX retain the old API node addresses even though these have been replaced by local addresses. If IoX is restarted AND the configuration includes only local addresses AND the APIKey has been removed; all fields are blank in the administrative console. I have never seen an administrative console screen or node server node listing that shows local_60 and local_107 has the node names. Given you have only one local sensor, you might try using the same local IP address for both sensors in your configuration and see what happens. Just a thought. Thanks again.. PurpleAir_2-22-2024_94007_AM.zip

Attached is today's file. There were numerous configuration changes in an attempt to isolate the issue. These are not annotated, so I will start clean tomorrow and annotate when any changes are implemented. PurpleAir_2-21-2024_14557_PM.zip

I will pull logs and send tomorrow. I currently set both sensors back to use the API. All is now working. I did try a couple of other things before giving up. 1) I set both sensors to use local addresses; 2) I removed the APIKey field; 3) I rebooted the entire platform. When I fired up the admin console all fields were blank for both sensors. I looked at the log and it showed that local_60 was setting values, but there was no sign that local_107 was doing anything. I next looked at the nodes themselves they were populated but they showed the sensor numbers as the node addresses (this shouldn't be). They were not updated when the configuration was changed. I thought that they might have been held in cache, but given the entire system, including PG3x was rebooted, that shouldn't (couldn't?) have been the case. My guess is these addresses didn't get changed when the configuration was changed to use local IPs. I cannot tell if the data being set in the logs is fresh or not. I understand you not being able to replicate the two local sensor configuration. If you wish, please propose configuration variants you would like me to try and I will annotate the log file where the configurations were changed. Will get that done in the morning. Thanks again...

I just updated to 2.1.1 and set both sensors to their local ips. I restarted the node server and restarted IoX. When looking at the admin console there were no values being received by IoX (all fields blank for both sensors). I looked at the node server log in realtime and didn't see any errors being thrown. I replaced the local Ips with their sensor numbers and the admin console immediately began showing values in all fields for both sensors. Hope this helps some.

Migrated this node server from PG2 (running in a Debian VM interfaced to isy994i). Never had this issue. Now running the PG3x version on an eISY v5.80 I am experiencing incomplete population of IoX. Looking at the node server logs, the values are being set and appear to be published. See attached screenshot of the admin panel and associated node server log. The node server hasn't been running for very long and IoX was restarted just prior to taking the console screenshot. Also, certain fields in forecast_0 and forecast_1 are not being populated on the IoX screens as well. Thanks for looking into this issue. AERISWeather_2-20-2024_21316_PM.zip

Thanks Bob, for providing this insight. I have not attempted to write a node server so I am not familiar with the messaging relationships between IoX and PG3x or what support might be available for error communication (outside of logging) for that matter. I have noticed that UDI does not wish to provide an ability to automatically restart node servers periodically due to a belief that it is the node server's responsibility to handle any errors. Thank goodness, UDI mobile does provide the ability to restart individual node servers without having to launch the admin console. I am currently waiting for another node server to be fixed where the node server in question stops updating IoX when it receives a message that the node server wasn't anticipating and therefore believes it to be "malformed." When that occurs the node server stops updating IoX and no one knows there is a problem until something that worked suddenly stops working. All automation using that node server is down until that node server is restarted. It would seem there are many reasons this situation might occur when a node server is attempting to interact with a third party device or service. API's can change even slightly or might be incomplete (contain undocumented messages). In my case, by studying the logs, I can find a unique sequence of events that causes the error and could write some IoX code to restart the node server when that sequence occurs, if a node server restart command was available. That would certainly help take the pressure off node server developers to respond quickly to this type of issue. Just a thought... Thanks again for creating many useful node servers..

Attached is the node server's log file and my sensor information. API key has been redacted. Initially both sensors were configured with their local addresses. To my knowledge only Local-60 would report information. When both were configured to use the API, they both reported. The final log reports were with "outside" using Local-60 and "inside" using the API. This configuration seems to report both sensors. I appreciate your taking a look at the log. PurpleAir_2-20-2024_124036_PM.zip