Ed Sybesma

When I go to install at the store, it is telling me that it is still version 4.0.0.

No matter what the chance of rain from other weather forecasts, the forecast for each of the next six days in OpenWeatherMap always shows zero (0). My temperature prediction seems to match well with other weather forecasts. This appears to have been consistently true for the last 3 to 4 weeks, ever since I updated to version 4.0.0.

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'

Understood, but when I first tried to run the IF and THEN routines, I had already manually set the variable value to 53 and my actual setpoint on the thermostat was 74. Under either the IF or THEN routine, the variable didn't change. It stayed at 53.

Larry, Thanks again for your input, including the programming tip. And you are right. The program did run and did update the variable when the setpoint was changed. I currently have this set as a state variable. I still wonder why I could not manually cause the program to run and change the variable inside administrative console using the run If or the run Then commands. In any event, it is working and I thank you. Ed

Larry, thanks. I am with you now. And I have created a program: If 'Indoors / Thermostats / 14.F8.3C - UPSTAIRS Main’ Cool Setpoint is not 99‘ Then vCool_Setpoint = ‘Indoors / Thermostats / 14.F8.3C - UPSTAIRS Main’ Cool Setpoint Else - No Actions - (To add one, press 'Action') I gave an initial value of 53 to the variable vCool_Setpoint. Unfortunately, nothing happens when I run either If or Then. Any additional ideas? Thanks again.

MrBill, Thank you for your input as well. FYI, I am trying to set a routine to increase or decrease the cool setpoint through an Alexa voice command.

Larry, Thank you for that input. Unfortunately, I don't find any condition "therm.setpt" In the programming commands available in my Administrative Console. Furthermore, my options for setting variables are limited to setting them from the drop-down box. Am I missing a module of some kind, or are you doing the programming somewhere other than inside the Administrative Console? My configuration is as follows: Firmware loX v.5.5.9 ( 2023-03-07-11:17:36 ) Ul loX v.5.5.9 ( 2023-03-07-11:17:36 ) Product Polisy (5200) · OpenADR (21010) · Networking Module (21040) · Portal Integration - UDI (21075) -Z-Wave Module (21100) · A10/X10 Module (21060)

For example, I would like to know the current state of the cool setpoint in my Insteon thermostat. How can I obtain that through programming?

Got it. Thanks much.

Back to where we started from then. That's what I originally thought. So is there something wrong with my ISY/Polisy? Because on one of the modules (but not the other), the heartbeat status keeps switching back and forth between ON and OFF.