bpwwer

The on-line status is for the node server to PG3 connection, not the node server to WeatherFlow device connection. WeatherFlow doesn't provide any method to query if it is on-line or not. It simply broadcasts data over your network and it uses a method that doesn't allow for any type of acknowledgement that the data was received by anyone. The seconds since seen is how many seconds have elapsed since the node server has seen a broadcast message from the hub. The hub sends out a couple of different messages at different intervals the main message being the one with the actual weather data in it. The main data message should come every 60 seconds. Rapid wind messages are every 3 seconds (or not depending on the state of the batter charge). And there are a couple of other messages it sends out. Since broadcast message can be lost or temporarily blocked on the network, there's no specific time. The value is going to vary depending on network load, when the hub was started, when the hub starts getting data from the Tempest device, the state of the battery charge. With all that being said, if the time since last seen gets above 2 minutes, chances are pretty good that something is wrong.

When the Polisy reports a uuid of 00:00:00:00:00:01 or something like that, it means that some component of the Polisy didn't start or is missing. You can attempt to run the "Upgrade Packages" option from the admin console another time (or two) to see if it corrects it. The process can take a while (like 20+ minutes) so don't start an upgrade process and then reboot/power cycle the Polisy shortly there after. If you can't get the upgrade process to run or running a twice doesn't fix the issue, you'll have to enter a support ticket at support@universaldevices.com

No, I'll clean up the change and push it to the production store.

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"