bpwwer

That's probably my fault. I added some code to PG3 to try and make sure the name matched in the PG3 database and the ISY and that may be doing some unexpected things. I also made some changes to the addnode function to give it the ability to rename nodes so I'd like to see the PG3 log entries for the time period when you deleted the node from the ISY and had the node server re-create it.

That's pretty strange. I didn't know you could move sensors to get them to report differently. I don't have an Ambient Weather system so have relied on getting access to other's data to develop the node server. My opinion of Ambient Weather's API is not very good. It seems to have been very haphazardly developed. So I wouldn't be at all surprised if it was sending something that caused the node server issues.

There was a support ticket with the same issue (uuid = 00:00:00:00:00:01). In that case a reboot of the Polisy resolved the issue. I suggest you try that first. If that doesn't resolve the issue, then file a support ticket as something may be preventing the Polisy from fully initializing on startup.

About the battery state. Ambient's reporting of batter state is all screwed up. Some sensors send 1 to indicate low batter and some sensors send 0 to indicate low battery. When I wrote the node server I didn't have multiple sensors and didn't realize this was the case. I assumed all would report battery state the same way and that's how the node server is written. Someday I may try to fix this in the node server but for now, it's a known issue. If the nodes are being created, that implies that the node server is seeing data from those sensors and recognizes that data. If it's sending that data to the ISY, then the node server is working properly. Node servers have no interaction with the admin console, that's all on the ISY. If you provide a debug log for the node server, including a restart of the node server, I can verify the assumptions in the statements above. Otherwise, from what you've said, the node server is working properly.

I installed the board in a Polisy Pro (without a Zooz stick) and after rebooting, it admin console shows the normal z-wave menu. I'm not sure what happens if both the Zooz stick and ZMatter board are installed. I do not yet have any z-wave devices added. I'm waiting for the migration instructions to go from he ISY 500 series z-wave to the ZMatter z-wave. I found that connecting the antenna cables to the board and then plugging the board into the Polisy was a bit easier than the other way around. Those cables don't have much slack to work with.

I have one of those too. Luckily, I had a newer one also so I swapped top halves of the cases. @Michel KohanimIs there a template available for where the holes would need to be drilled?

The cause seems to be that "api.emporiaenergy.com" isn't being resolved. It could be a temporary thing where their servers when off-line for a while or it could be something regional/provider related where they aren't able to contact root DNS servers. Or it could be a local issue (I.E. your internet connection was down). I'm able to resolve the name here and I'm able to access the server. You can try with a browser using https://api.emporiaenergy.com and it should respond with an authentication error. The main error is "<urllib3.connection.HTTPSConnection object at 0x8052eb820>: Failed to establish a new connection: [Errno 8] Name does not resolve" It does make multiple attempts and then reports that max re-tries exceeded. Then the node server throws a bunch of errors because it didn't get any data from the servers.

I'll make a node of the new fields. Ambient seems to constantly add new fields. If the node server is reporting the data, then the problem is the admin console. Have you restarted the admin console? You can also try re-sending the profile files with the upload profile button in PG3 (and then restarting the admin console).

I don't see anything wrong (other than it not updating). I did just re-upload the package file since it's possible I made the package but forgot to upload it.

I made the change to comment out the pushover import since I do have access to the repository. A re-install should get a working version now.

There are two ways to to re-install, the other way is to go to the full store listing, select the node server, and select "Install" there. In theory, both ways should work but there are some differences and for some node servers those difference currently cause some false failures.

It's possible they've changed the API to not accept all the methods they use to accept. I don't have time to track the changes that all the different services make over time. Also, I posted the raw (unformatted) text from the help box so it contains the markup code as well. What should be displayed in the help text and what you enter are "postal_code"

PG3 was never designed to allow any type of migration of node servers. When it installs a node server it configures the node server on the ISY to point back to itself and it stores information about the node server in it's database keyed on the ISY UUID. When you migrate from ISY to IoP, the IoP should end up with the node servers installed. But PG3 won't have any knowledge about them since it's database won't have any node servers that use the IoP UUID as the key. Thus, when you switch PG3 to use IoP as the selected ISY, all the node server's will show as unmanaged. In theory, you may be able to change all the database records to use the new IoP UUID but given that it's a key field, I'm not sure it will allow that. You can do a re-install of the node servers which will create new database entries for them without having to delete them from the IoP, thus all programming, etc. on the IoP that use the nodes will be preserved. However, you will have to re-configure the node servers in PG3 so make sure you document their configuration before you do anything. Also, it would be a good idea to backup PG3 just in case you need to go back and look at something. I believe that the following steps should work: 1. Select the IoP as the currently selected ISY in the ISYs menu on PG3. 2. Look up each node server in the node server store and use the "Install" button to re-install it. 3. The install dialog should have a option to re-install to the slot where it is currently listed as unmanaged. Select the re-install. 4. Re-configure the node server and everything should be working as it was before the migration. With your current setup with PG3 configured to talk to both the ISY and the IoP, you can switch it between the two to compare configurations. So I would recommend that you keep it like that and not rewrite the ISY IP/port with the IoP IP/port. Once everything is working with IoP, then you can simply delete the ISY configuration from PG3.

The node server has been available for over a year and you're the first to notice that that the notice messages have the wrong service in them. Pushed out version 2.0.6 that fixes the messages. It's the weatherbit service so it uses the weatherbit.io API key. I'm not sure which documentation you're referring to. The configuration help text says: The WeatherBit.io node server has the following user configuration parameters: - APIkey : Your API ID, needed to authorize connection to the WeatherBit API. - Elevation : The elevation, in meters, of the location. Default is 0 - Forecast Days: The number of days of forecast data to track* - Location : Location to get data for. Can be specified as: - lat&lon Ex: lat=38.123&lon=-78.543 - city,state Ex: city=Raleigh,NC - city&contry Ex: city=Raleigh&country=US - city\_id Ex: city\_id=8953360 - station Ex: station=KSEA - postal\_code Ex: postal\_code=27601 - postal\_code&country Ex: postal\_code=27601&country=US - Plant Type: Used as part of the ETo calculation to compensate for different types of ground cover. Default is 0.23 - Units : M for si and I for imperial. Default is M *The number of days of forecast data and poll times depend on the plan. - Free plan, 7 days max, short poll 1800, long poll 43200 - Hobbyist plan, 7 days max, short poll 250, long poll 21600 - Starter plan, 16 days max, short poll 60, long poll 3600 To get an API key, register at www.weatherbit.io What's not clear about that?

Are you using Wifi to connect to the Polisy? If so, the upgrade probably changed the hardward ID PG3 uses for licenses. You'll have to submit a ticket and get the licenses moved over to the new hardware ID.

I don't see any errors from PG3, just warnings. I've mentioned this before, PG3 makes 3 attempts to send the information to the ISY. Above shows that the first attempt failed, but the second attempt succeeded so that's not an error.

@wrj0I'll have to take a look at that. Both areas should do the same thing but there are currently corner cases where the re-install from the purchases page has to make assumptions. Sometimes it gets them wrong. This should get better as both the node server store entries and as everyone updates to the latest PG3 but it could take a while before that transition is complete.

I think you almost had it right. Try ${sys.node.n001_141766_11.CPW} The address created by the node server has the "n<slot>_" pre-pended to it when added to the ISY

A 404 error from the ISY means not found. As to why it's returning that, I have no idea. I would think that if it really wasn't found it would never update on the admin console. But I don't know anything about the ISY software.

Looking at the log I see that the node server seems to be having problems parsing the ISY error log. So possibly something unexpected is showing up there. However the node server is failing because: 2022-10-31 11:37:42 error: POLY: MQTT Error: Connection refused: Identifier rejected Which means that there is already a copy of the node server running and connected using that same slot and PG3 will only accept connections from one node server per slot. I did recently find a bug where if you pressed restart while a restart was in progress it would cause PG3 to think the first restart failed (which would mark the node server as disconnected, but the node server would stay connected. The second restart would try to start the node server again, but it gets rejected by PG3 because the first is still connected. The message above is what you see when that happens. A restart of PG3 should correct it.

Sorry about that. You didn't do anything wrong. A re-install is not supposed to touch the configuration but that was added to a fairly recent version of PG3 (3.1.12). In my limited testing, it seemed to leave the parameters in-tact when re-installing but there could be a bug.

When did you purchase Polyglot and Pi4 Servers from UDI? The software you are using was not written by UDI. Neither it nor Pi 4 hardware are UDI products. If you're looking for support for Polyglot V2, the git hub is here: https://github.com/UniversalDevicesInc/polyglot-v2 You can open an issue there but won't likely get support for that either as the person that wrote it is no longer actively maintaining it.

The current auto-upgrade process in 3.1.14 is buggy which is why I think he resorted to a re-install. But that's good advice in general.

The PS shows the kasa node server has been running since sometime on Tuesday. So it was running when you tried to restart it today. However, for some reason PG3 thinks it is not running. That's why you got the message that it wasn't running when you tried to restart it. When you re-installed it, it started the kasa node server (copy 2) but PG3 rejects it's attempt to connect because copy 1 is still connected. If you kill copy 1 (4728), it will disconnect from MQTT and if copy 2 is still attempting to connect, it will succeed. If not, it should now start by either pressing Start or Restart.

I'm not sure how many more ways I can say this. PG3 is not getting proper responses back from the ISY. There's nothing PG3 can do to make the ISY respond or respond in a timely manner. In the log you attached, there are many cases where it's taking 10+ seconds before it finally errors out waiting. I also see cases where it's taking almost that long on the third try to get a response. Requests to the ISY that should take less than 100ms are taking 100 times that long and then many are just outright failing. That's why you see so many node locked, waiting messages. That's exactly what PG3 is doing, waiting and waiting and waiting. When you see an unhandled exception / unhandled rejection it meas that something very unexpected happened, likely a compounding of error responses to the point that it doesn't know what to do.