bpwwer

As it's being used to day in PG3, connection status is reporting the connection status of the socket connection between the node server and PG3. This is monitored and reported by PG3, not the node server. If that connection is alive, PG3 reports 'connected'. Depending on how the connection is closed, if by PG3 stopping the node server: 'not connected'. If by the node server crashing and dropping the connection: 'failed'. However, in the node, the connection is maintained by a thread while other threads are used for other tasks within the node server (say to maintain a connection with the hardware it supports). Thus it is entirely possible for the some parts of the node server to fail while the connection to PG3 remains alive. Also, node server don't have to make use of the PG3 connection status. At this point, I believe almost all node servers that report "Node server Online" are using the PG3 connection status, but I'm not sure. Node servers could report the connection status of their connection to external devices but if they do, I would think they'd use a different name for that.

There are no custom typed configuration parameters for this node server.

Just to add some clarity, there is not an error "db_getNodeDrivers: controller not found in database". That is a WARNING. It may or may not indicate something is wrong. It is more of an informational message for node server developers. There are cases where not being able to find something in the database could be the reason for something not working as expected and there are cases where this is normal. In this case, since it happens right at the start, it most likely is because the database that it's checking has not yet been loaded and is empty so it is an expected warning. Remember PG3 is in a alpha state. There are going to be a lot of log messages that won't be of much use to users but are there to help developers debug.

I think you're seeing the difference between historical data and current data. The node server is always showing current data and only current data with the exception of rain accumulation (month, year, etc). I believe both remote and local get the same data over the last 1 minute interval. So the node server is only reporting data obtained over that 1 minute interval. I don't have any insider knowledge about how their app works, but they very well could be showing the last lightning strike detected vs. any detected in the last 1 minute. The node server is designed to allow you to trigger off of and make decisions on the current data. Where something like the app is designed to show what's happened/happening. Different goals. When configured for 'remote' data, all data comes from the WeatherFlow servers.

Sure. I'll add that to the TODO list for that node server.

The choice is yours. When you configure the node server the station ID is marked as either "local" or "remote". Local means direct from the hub on your local network, remote means from the server in cloud. The 'remote' option was intended for people that have a weatherflow at a second, remote, location that they want to monitor. But it works fine for a single/primary location as well. Originally, the Tempest (or maybe it was just a subset of them) wasn't reporting any lightning data yet the app would still display info. This caused many node server/plug-in bug reports. And as you've noticed, WeatherFlow doesn't really make it obvious that they do massage the data from the sensors before sending it the app.

Thanks for the information. The problem is that the ISY doesn't really have a way to deal with a dynamic number of items, it always wants a fixed number of items in a node. So I don't know of anyway to make it work much better with the limitations imposed by the ISY node model.

You're lucky I saw this, it was in the wrong section. I've moved it to the WeatherFlow section for you. Lightning will never match with the app if you are using local data with the node server. WeatherFlow uses your stations local data plus other stations and other sources to calculate the lighting data it displays on their app. The node server is only using your stations local data**. The same can be true for rain data where they manipulate that in the servers to provide more accurate than what they get from the sensor data alone. The ISY doesn't currently deal with time data very well. Is there a specific use case where knowing that data would be useful over # strikes and distance? The local sensor is reporting real-time data for this, not accumulative or historical. I.E. # of strikes is reported like:1 0:00:00 - 0 strikes, 0 distance 10:01:00 - 1 strike, 5 miles 10:02:00 - 0 strikes, 0 distance ** The node server can be configured to pull the data from the server instead of the direct local sensor data. In this mode, it should match.

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.