bpwwer

That's strange. That node value string is defined by the nls key "ST-ctl-GV1-NAME". These should be unique per node server slot. For the PG2 version of WeatherFlow, that is assigned to "Sky Battery", for Elk it should be "ELK M1EXP Connected". @JimboAutomatesI see that you dynamically create the NLS for Elk, is it possible that this isn't getting written out and it is using something that was in that slot previously?

I don't know what's going on with the backup. Last time I tried it it did work. It's possible that me switching between a development branch and release branch to make the bug fix, that something isn't getting setup right. But why it seems to only effect the backup button, I don't now. Thanks for letting me know. I'll make sure to check it before doing the next release.

Ping me on slack after you do that and I'll verify it's all there and if not, we can figure what I've broken.

Yes, this definitely needs some work. The process that I've been using to notify developers and testers of new PG3 is a stop-gap solution.

The RainMachine package was last updated Feb. 10th on the server so this may be another case of not uploading the new package when updating the version. It's any easy mistake to make with the current upload tool. I'll have to see if I can improve the tool to check for this case.

Correct. I'll let @JimboAutomatesknow that he needs to update the package. @dwengrovitzSee if you can start it now. It may have been trying to update but failing because of the missing package.

I think I see why it's failing to install. Looks like @JimboAutomatesupdated the version but didn't upload a new package. I copied the old package over so it should install, but I think it might not be the latest version. But go ahead and try installing it now and let me know what happens.

Yes please. @macjeffor @vbphil if you can send the PG3 log from when you tried to install and it failed, that would help too.

Can you try restarting it again and then go look at the PG3 log? Usually, when the node server log doesn't update, it means the node server never started, the reason it isn't starting is probably in the PG3 log.

That error doesn't seem to be causing the issue. It looks like it starts waiting for data from the first device and never gets what it's waiting for (but from the log, it looks like the data was sent). So I'm not sure what is happening yet.

It will only delete the node servers that were installed using PG3. It won't touch the node servers installed by PG2.

Try version 2.0.2 I only have one Roomba so I'm not able to test if it works with multiple.

Try restarting now. It auto update to version 2.0.1 of the roomba node server. This version is configured differently from the PG2 version. When it starts, it will search for Roomba's on your network and then prompt you to press and hold the home button of each to connect them.

I updated the link in the store listing so it should work now.

Not just you, it appears to be broken. I changed the backend of the backup proccess but didn't touch the UI portion and it's the UI portion that appears to be not working. It was working when I tested my changes. Go figure.

I just published version 2.0.1 that fixes at least some of the issues. Restarting the node server will automatically do the update to the new version.

You see a lot of these issues with the weather services for a couple of reasons. The weather services tend to have a lot of data so I tried to minimize how much was sent to the ISY and most will only update when there are actual changes. Because the i994 ISY has limited network resources, this is probably less of an issue with IoP, but since the node servers still support both, it's not going to change right now. The weather services tend to limit the number of API request so I don't enable interactive query since overuse of that could cause the limit to kick in and you'd end up getting no data until the limit was reset. In some cases, the weather services just aren't sending that particular data for your specific location. In that case, the node server will send the default data when it starts and it will never send it again until it is restarted because it never gets updates from the service. Or like #3, the data is sent very infrequently. NOAA alerts for example are only sent when there is an alert published. Lastly, most of the weather service node server were written for a early, pre-alpha version of PG3 and do need updates to work better with the current version of PG3. That's on the list but low priority at this time. Also, since this is only an issue if the ISY is rebooted, the work around at this time would be to restart the node servers after the ISY is rebooted. If you are having to reboot the ISY frequently for some reason, that is a bigger problem and should be addressed.

You can delete them, it should be creating new logs each day. PG3 uses /var/polyglot/pg3/logs

There are two different things being discussed above, but both may have the same root cause. If the ISY is not available when PG3 starts, it shouldn't effect the ability for PG3 to start node servers. If PG3 fails to start the node server, then that is probably a bug. However, if the ISY is not available, then PG3 then all status updates to the ISY will fail. Because PG3 typically only sends status updates when the status actually changes, if the ISY becomes available after PG3 has given up, it won't try to send updates again until the status changes again.

I don't know what that node server does so I don't know.

The log files are in /var/polyglot/logs They are supposed to restart each day and archive the previous day's.

What I was trying to say above was that in many cases, this is the expected behavior with the current PG3 design.

Node server status is just the status of the MQTT link between PG3 and the node server. It only changes when the node server is started or stopped. Restarting the ISY, has no impact on this. The ISY is clearing the status when restarted and unless the node server is stopped and then restarted, it won't send any updates to the ISY. Typically PG3 will try to minimize the traffic to the ISY so it won't send a status update unless the status has actually changed. Since the status hasn't changed, no update is ever sent. With PG2, the node server status was handled differently and what it reported was different. There could be other differences around when it would/wouldn't send updates as it was not trying to minimize the traffic like PG3 does. Thus PG2 and PG3 are not expected to behave the same.

Looks like one of the dependencies can no longer be installed on a Polisy. It will take some work to figure out if this can still be supported or not.

The node server store support is currently in-flux as I work to improve it. One of the goals is to eventually remove the 'install local node server' button in favor of installing from the 'local store'. This will make the process for developers be as close as possible to the same process users will use to install node servers. However, with the current release, there isn't any way to get node servers into the local store. That's what I've been working on for a few days now. While the local store is primarily intended for developers, it can also be used to provided pre-loaded nodes servers on the Polisy so that some node servers may be available even if the Polisy doesn't have an external network connection or the cloud based node server store is down for some reason.