Ed Sybesma

Got it. Thanks. Everything is working fine right now, and hopefully it will stay that way, but if I encounter the problem again I will send you the full log package. Thanks again. Ed

Attached is the debug log. It only goes back to 2024-06-16 16:38:33. I assume that is because that is when I reinstalled OpenWeatherMap to see if that would solve the problem. The log appears to indicate that OpenWeatherMap connected at 16:38, but that does not correspond to what was shown in the Administrative Console. The log also indicates that it connected at 17:00, and that corresponds to the time when I received the notification indicating there was a successful connection. debug.log

Addendum: my Administrative Console has now reconnected. And I now see that I have a great many notifications on my UD Mobile app for today, June 12, and June 9, showing OpenWeatherMap being repeatedly disconnected and then reconnected. I don't have any such messages for any other nodes or plug-ins. Any idea where this issue is coming from?

I have updated to version 4.0 of OpenWeatherMap, and it installed properly on my Administrative Console, except that it is consistently Disconnected and receiving no new data on the Administrative Console, even though it is showing as properly connected on PG3. There was a prior thread on this issue, but I did not see a solution in the thread and the thread was closed. What is the solution?

Geddy, Thank you for your assistance. I have now done all of those things you suggest (except that for some reason I could not connect at all through my alternate browser, Microsoft Edge, so I stuck with Chrome). Nothing worked to restore my Ring node server purchase. I ended up repurchasing it and everything is working fine now. I will cross my fingers to hope it stays that way. Again, thank you very much for your help.

If by "full power cycle" you mean a reboot, yes, I have done that within the last week-before this problem arose. I have not done it since the problem arose. IoX: 5.8.0 PG3x: 3.2.17.

It is asking me to purchase the license again. It is only nine dollars, so it would be no big deal except that if something is broken, that may not exactly be a fix.

One of my plug-in purchases is the Ring plug-in. Because it was not connected, I just tried installing it again. It initially installed properly and was working very briefly. I then went to install my Notification plug-in. When I did that, the Ring plug-in disappeared from my Dashboard of plug-ins, and it also disappeared from the list of Purchases. In the list of Purchases, it was replaced by a beta of Notification. How can I retrieve my Ring plug-in?

Once again, thank you for your assistance. I am going to open a ticket because going back and unlinking and relinking once again gave me the HTTP error message and resulted in anomalies with the connection with Alexa.

I had not tried it this morning. I did go back in just now and made another change (just adding a room name), rather than unlinking and re-linking. The change I made was immediately recognized in the device list, without having to close it and reopen it. The HTTP error did not show up. Yesterday, that kind of change resulted in the HTTP error and required me to close and reopen the device list. So it appears that your fix this morning did resolve the problem I was having yesterday, but may have created a new one: A new anomaly showed up. I received the following dialogue message: Skill not linked The Alexa skill is not linked. You can continue to add/edit your spoken mapping. When you are ready to link the skill, your devices configured here will be synchronized to Alexa. Contrary to that message, however, the skill was in fact linked. It had been linked before and was still linked. thank you for your ongoing assistance.

I have done that a few times and eventually it gets straightened out in Alexa, but not always. In fact, one time I did that it resulted in Alexa discovering the device twice. So I had to repeat the process before it got finally straightened out. And each time I link or unlink a skill, I get the “HTTP error 500” error message and then have to close and reopen the device list inside UD Portal before the change is reflected in the list.

For the last three days, whenever I make a change in my Amazon Echo device list inside UD Portal, whether it be to add a device, delete the device, or add or delete other information such as Spoken, as soon as I hit apply I get an “HTTP error 500”. The change I make generally does not show up until I close and then reopen the device list. The change I make generally does not show up automatically in Alexa and instead I have to instruct Alexa to “discover my devices”. And then the discovery process is strange. A couple times it failed to discover something or, in one instance, discovered it twice. I saw that there was a topic on this “HTTP error 500” issue a couple months ago relating to login problems. I am not having trouble logging in.

I have the Zooz dongle and loX v.5.7.1 (2023-11-09-11:49:34).

In the administrator post dated October 2, regarding the current recommended process for updating the eisy and Polisy products, it recommends running a Z-Wave backup first, separate and apart from the IoX backup, and says the backup can be started from Menu > Z-Wave > Backup. I have Polisy Pro with Z-Wave, but there is no option for backup under Z-Wave in my menu. What am I missing?

In response to your specific question, that first happened In the early morning hours when the setpoint was programmatically changed to 74 through a different routine. But the more interesting set of issues that now arise is that my upstairs routine for setting and changing the Setpoint in both the variable and the thermostat is consistently working properly as would be expected. And yet I have what is an identical (other than variable names and thermostat device) program for my downstairs thermostat which is behaving erratically. For example, when the setpoint on that was changed to 74 in the early morning hours today, the variable did not change from his prior setting. Sometimes this downstairs routine works and sometimes it doesn't. One time it even changed the thermostat mode setpoint to 73 while leaving the variable at 74. That seems impossible, but I did observe it. My initial reaction was that maybe the downstairs thermostat wwas farther away from my PLM and maybe the signal from the thermostat wasn't always reaching the PLM. But that thought seems to be dispelled both by the "impossible" behavior described in the last paragraph above, as well as the fact that the setpoint is always reflected accurately in the Administrative Console report for the downstairs thermostat module itself. For whatever it's worth, here are the two routines being used for my downstairs thermostat: Program Content for 'Set $vDownstairs_Cool_Setpoint Variable to Current' If 'Indoors / Thermostats / 14.F9.CF - DOWNSTAIRS Main' Cool Setpoint <= 120‘ Then $vDownstairs_Cool_Setpoint = 'Indoors / Thermostats / 14.FS.3C - UPSTAIRS Main' Cool Setpoint Program Content for 'Increment Downstairs Cool Setpoint' If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then $vDownstairs_Cool_Setpoint -= 1 Set 'Indoors / Thermostats / 14.F9.CF - DOWNSTAIRS Main’ Cool Setpoint '$vDownstairs_Cool_Setpoint Degrees' Else $vDownstairs_Cool_Setpoint += 1 Set 'Indoors / Thermostats / 14.F9.CF - DOWNSTAIRS Main’ Cool Setpoint '$vDownstairs_Cool_Setpoint Degrees'