bpwwer

Yes, but... the ISY and IoP don't really communicate state between them. So while the ISY can continue to manage z-wave devices having them interact with other devices (scenes, programs, etc.) on the IoP isn't going to work. Given what you posted about your setup initially, I don't think you want to try and do this. I haven't read through everything about, but it sounds like you're trying to decide if you should spend the money on a z-wave stick for the Polisy now or wait for the new UDI z-wave dongle. My question is, what is compelling you to want to migrate now (as opposed to waiting a few months)? Is there something specific that IoP will solve now that the ISY isn't able to do? The big difference between Polisy and Eisy is performance. There are some I/O differences as well but those will really only effect limited use cases. For node server development, there should be very little difference. Node server development doesn't typically run into performance limitations on the Polisy. Just for reference. For doing PG3 development, the UI build takes about 5 minutes on a Polisy and I expect that to improve by at least 10x on an Eisy.

Thanks, that answers the question as to where the failure is. To me, it looks like the first program should evaluate to true and the second to false. You're saying it is doing the opposite. So either we're missing something or the logic is failing. Someone better versed in ISY programs will have to look at this. You could also try creating programs for each condition separately and see how they evaluate. Or try setting a variable to the value to the eto value in the then or else sections. The node server doesn't have anything to do with the program evaluation other than providing the value, which it seems to be doing correctly.

I don't believe the ISY/IOP rounds the value. I think it just truncates the display to the number of decimal places the node server specifies. The node server is rounding the value to 3 (maybe 2) decimal places. If the ISY/IOP was rounding up, the second program wouldn't be true. @CoLongplease just post the value the node server sends, that's what's important here.

Either the program logic is correct and the value is between .270 and .299 and the displayed value is truncated or the program logic is failing and the displayed value is correct. It either case, it's not a problem with the node server so there's nothing I can do about it. Looking at what the node server actually sends to the IOP will tell us which of those cases is true and the appropriate ticket can be raised to UDI.

Yes, UDI's upgrade script failed. As part of that upgrade it is supposed to re-install all the python packages so that all the 3.9 versions are installed, but that doesn't seem to have happened. I don't believe there's any user accessible way to fix this, right @Michel Kohanim. Other than removing and re-installing each node server.

What is the actual value of ETo being sent to the IOP? You're seeing what the AC displays, but not what the node server sent. My guess is that the value is between .270 and .299. It looks like the AC isn't honoring the display properties the node server requests. The node server says that value should be truncated to 2 decimal places, but it looks like it's truncating it to 1.

Just FYI, the "errors" in the node server log aren't really errors. I just forgot to change them to debug message.

@Michel KohanimWhat would cause the AC to show writing to a node server node? Would there be something in the log or error log to explain why it's doing this?

Not that I know of. The precipitation info uses a different query from the rest of the weather data. It seems just the query used for the precipitation data had changed.

Yes, not having direct access to the equipment can make developing a node server more difficult. But more than that is the time it takes to develop and support it when you don't have easy access to the equipment. The bottom line with node servers is that unless the developer plans to use the node server themselves, it's just not real cost effect to develop one. A professional software developer makes something like $100-$150 per hour. Creating a node server will take between 50-100 hours. So the upfront cost to develop one is between $5000 - 15000. That means that to try and break even, they'd need to sell a minimum of 100 copies at $50 per copy. From the sales data I have for the past 7 months, my highest selling node server is less than 40 copies. I don't have access to any other developer's sales number, nor do we track installations to know the quantity of "free" node servers that are in-use. So I don't really know the size of the potential market for any given node server. That being said, my criteria for developing a node server isn't really based on the ROI, I do most of them because I like developing them. I would certainly consider working on expanding the existing Vue node server to handle their other devices, but I really don't have the time right now to do that.

It's not something I have time to take on at this time.

Yes, it is the same issue. Version 3.0.23 should fix it.

The Vue node server only support the VUE utility connect energy monitor. https://www.emporiaenergy.com/how-the-vue-utility-connect-works It doesn't support the any of the other VUE energy monitor devices.

No idea what that means. From what I understand of that state, it means the ISY is trying to update the node configuration and that should only be possible for Insteon and z-wave nodes. If you restart the AC does it continue to display that?

Verstion 2.0.7 of the node server should fix this. AERIS changed the format of the precipitation data in the query response.

This is the problem: 24:00:46 [pg3] error: ISY Response: [Try: 1] [00:0d:b9:53:d8:14] :: [404 - OK] :: 18.856618ms - http://192.168.2.117:8080/rest/ns/7/nodes/n007_controller/report/status/ETO/2.903759505852784/106 The ISY is rejecting it. A 404 error means "not found". I did some experiments and it seems the ISY rejects it if there are too many digits of precision in the value. I just pushed out version 3.0.22 that rounds the value so this should be fixed. If you refresh the node server store, and then restart the WeatherFlow node server, it should auto-install the update.

The setup looks correct. If PG3 is displaying a value and that value is changing from day to day, then the node server is working correctly. The node server never talks to the ISY directly, everything goes through PG3. So if PG3 has the right value and the ISY doesn't, it's not an issue with the node server. You didn't mention any other problems, but if it's just that one value that isn't getting sent to the ISY, that would be very, very strange. The only thing I can think of that might cause something like that would be if the node server's profile file on the ISY was missing the ETo definition, but the AC does get the proper definition. You can try re-sending the profile files to the ISY (PG3, node server details, upload profile button) and see if that helps. Otherwise, I'd suggest checking the node server log and look for when it sends the ETo value to PG3, should happen within a minute or so of midnight. Using the timestamp from that, check the PG3 log for the same time and see what it does with it. There should be log entries there showing it sending the value on to the ISY. Then at least we know if the value is making it to the ISY or not.

ETo is set to zero if there isn't any forecast data. The node server will enable the ETo calculation only if the custom parameter "Forecast" value matches a station ID returned when it queries the WeatherFlow servers for station meta data.

Unless you have a backup of Polyglot, you can't. The information about node servers is stored in a database, when you factory reset the Polisy, you removed that database. If you have a Polyglot backup, restore it and you should be good. Otherwise, you'll have manually remove the node servers from the ISY (node servers -> configuration -> slot #, and click delete) and then re-install them from Polyglot.

The query isn't returning data in the format expected. If you turn on debug level logging, the log will show the actual URL that is being used to query AERIS. Note, that URL will contain your secret API key. But I'd need to see the output from that query to know specifically why it's failing.

There was a bug about 6 months back that set it to zero after the first day, but that should be fixed. I see mine is at zero also so I'll do some debugging. It does need forecast information to calculate ETo and it does the calculation at midnight using the previous day's information.

Check the log, it will log any errors encountered while querying for that data.

I only suggest that to try and determine if there is something specific your doing or using that causes this. It may well be that the ISY is just overloaded. It has limited processing power and fairly limited TCP/IP stack. The IoP will certainly help as it has significantly more processing power. I have a lot of influence over what is done in PG3 as I'm the only developer working on it. But not much influence over the ISY software. #1 PG3 does support the ability for a node server to restart itself as that's currently the only way it can be implemented. The ISY doesn't have any built in methods to control node servers and it would be a pretty big project to add that. We can discuss this, but I'll make no promises. #2 is a possibility. Right now, I don't know of anyone else having problems with the current startup process and there are folks that run quite a few node servers. I've had near 25 starting and have not seen the issues you have. Of course this is with IoP with no programs running on it. Because node servers can vary quite a bit in how long they take to initialize, it may be hard to tune something like this. It can't be too long, a couple of minutes and you could have systems that take 30-60 minutes to start. A few seconds may or may not help. #3 is already being done. PG3 has both a per-node server queue and a global queue for messages being sent to the ISY with retries if they fail. In your case, the ISY either doesn't respond (which will cause PG3 to give up) or it is responding with an error that indicates a retry wouldn't help. You log did not show any cases where PG3 was retrying requests. It didn't look like there was enough traffic to trigger throttling. I do understand about all the programming needed to deal with HVAC. For a while I had a lot of programming for mine that took into account windows being open, inside vs. outside temperature diff, etc. The data was coming from WeatherFlow, my alarm sensors, and the thermostat. It controlled the thermostat and an whole house fan. I disabling most of it at one point when a window sensor failed and I couldn't get the whole house fan to turn off.

So I'm clear, the only thing running on the Polisy right now is PG3? I'm assuming you did some experiments that prompted you to set up the Polisy reboot when the ISY stops/starts, why? What happens if you don't? PG3 shouldn't care if the ISY stops or crashes, other than it will fail to get info from it and fail to send information to it. I don't believe it opens any connections to the ISY that it expects to say open until it is restarted. If it's not able to restore operation when the ISY comes back up, that would be a bug in PG3. Clearly data is being sent to the ISY, the event viewer log shows that as do the node server and PG3 logs. If the ISY isn't doing anything with that data, then it's a problem with the ISY. As I mentioned previous, the PG3 log shows a lot of failures communicating with the ISY when it starts up. When PG3 starts, it starts all the node servers which can generate a quite a bit of traffic as it tries to make sure the ISY is fully up to date with each node server's current status. With all the random failures it's getting, it's not really surprising that you're having issues. That would explain why restarting the node server when things are a lot less busy allows it to fully update the ISY and work. You obviously have a complicated setup on the ISY which means it's going to be difficult or impossible for anyone to replicate what you're seeing. There are a few things you could try that may help narrow down the problem. 1. You could stop all but one node server and restart PG3 and see if you still get the communication failures on startup. (If you manually stop a node server, it won't automatically restart when PG3 starts). You could try this with each node server, maybe only one really impacts the ISY. 2. With a good backup of the ISY, you could try disabling or removing all programs and then restart PG3 and see if it still has failures starting. Maybe a program or set of programs is causing so much load that it can't handle starting multiple node servers. Based on what I've seen in the logs it seems like the ISY is just overloaded and there may not be anything anyone can do about that.

I just saw you posted the PG3 log in another thread so I can provide more updates here. Looking at the PG3 log. At 10:50:52 PG3 scheduled the request to send the temperature value to the ISY: 7/21/2022, 10:50:52 [pg3] debug: Scheduling http://192.168.200.251:80/rest/ns/8/nodes/n008_s_2930073475/report/status/CLITEMP/23.6/4 to group statusGroup It got a response back from the ISY indicating it was successful 7/21/2022, 10:50:52 [pg3] debug: ISY Response: [Try: 1] [00:21:b9:02:55:cd] :: [200] :: 1526.422921ms - http://192.168.200.251:80/rest/ns/4/nodes/n004_controller/report/status/CLITEMP/26.93/4 So again, I see no indication that anything is wrong. PG3 is getting updates from the OWM node server and passing those on to the ISY successfuly. I'm confused as the PG3 shows PG3 communicating just fine with the ISY until 02:13:52, that's the first time a request from PG3 to the ISY failed. It continued failing until 09:53:05 when it looks like the Polisy was rebooted. PG3 restarted started at 10:10:33 At 10:10:54 PG3 sends some info to the ISY and the ISY responds with success. At 10:10:57 PG3 sends a /rest/nodes request and the ISY fails to respond. But then other requests after that are successful. At 10:11:07 PG3 tries to add the OWM controller node to the ISY, this fails with a "bad request" error, however, it's not a bad request. This continues for about a minute with various "bad request" responses, successful responses and no responses to the PG3. This is all happening while node servers are trying to initializing. It appears that the ISY is struggling to keep up. It mostly clears up after that, but the ISY is still not responding to the /rest/nodes requests from PG3. For the next few minutes there brief periods where the ISY fails to respond to PG3 but then it starts responding normally. Probably as node servers finish their initialization. From that point everything is normal until it is restarted at 11:03. After the restart, I see the same errors happening where the ISY fails to respond to PG3. PG3 restarts place a heavy load on the ISY as node servers start and initialize. On your system, it seems like it takes 5-10 minutes after a PG3 restart before the load on the ISY decreases to what it can handle.