bpwwer

According the log file, none of the node servers are starting because python isn't available. python is an OS level component on the Polisy and is what actually runs the node server code. STDERR: env: python3: No such file or directory I'd try doing an "Upgrade Packages" again from the admin console. Maybe something the last time and some stuff didn't get installed that should have.

I think I see the problem. This is the first "roku" device it finds: http://192.168.1.134:40000 which doesn't look like a roku device at all. So something else is responding to the roku discovery broadcast. I just uploaded a new beta that may resolve the issue. All it really needs to do is skip this non-roku device and continue and it should find the real roku devices.

You can try re-installing the beta version. Use the option to re-install it to the same slot you used before (non-production store -> Roku -> install -> re-install This version should at least show what it finds during discovery.

Well, that change didn't do what I wanted, I'll have to make another version.

That error is happening in the roku python library that the node node server is using. I could make the node server handle the error better, but I'm not sure I can do anything about the library failing. It is finding a Roku device (or devices) but the data it's getting back when querying the device is not what is expected. I just created a version with some error checking and additional debug. It's in the non-production store and is version 2.0.3. (refresh the store if it still shows version 2.0.2) You can install this version either by re-installing in the same slot or installing to a new slot and then download and post the node server log here (I don't need the log package).

From this log it looks like PG3 didn't detect that there's a new version and thus it didn't do the autoupdate. There are two places where it checks for updates. 1) when it pulls a new copy of the node server store data, it compares it with the copy currently in PG3 and if it sees an installed node server with a new version it creates the notice. 2) when a node server starts it compares the version that was running with the current node server store version and auto-updates if they are different. It sounds like the first is working correctly but the second may still be buggy. I don't have time right now to look into it as I'm busy helping to get things ready for the eisy and we're on a deadline to get the initial image done. Once that's out of the way I can start looking into the issues again.

Changing the configuration doesn't delete any nodes. You'd have to delete the node from PG3 which should then also delete them from the ISY. Both the ISY and PG3 keep a record of what nodes were created. If you delete from just ISY, it doesn't notify PG3 and thus PG3 continues to have a record of those nodes. Depending on what steps you actually took back then, this may be expected behavior.

It's not the node server it's the ISY/IoP that won't accept the precision. The node server is converting units and the conversion results in more decimal places than the ISY/IoP can handle. Fixed in version 3.0.26

OK, well I won't complain too much about it fixing itself The update process can sometimes take a while and restarting PG3 can also take a while now. So it's possible that when you first tried, things weren't fully initialized and it just need a bit more time to finish up.

I also have it installed and working with 1 zwave switch. I have a room with an Insteon motion sensor that triggers the switch and the switch is in an awkward position in the room so I wanted it working now. I did an exclusion to remove the switch from the i994 and an inclusion with IoP and it is working fine. I'm waiting for migration instructions for the rest of my z-wave devices.

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.