bpwwer

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.

You go to the configuration page and enter your Emporia username and password and save.

This is maybe not the best place to discuss some of this. I've some similar discussions over slack. If we want to create nodes that represent the node servers, I think we should make that mandatory and provide a well defined definition that lists what is required of those nodes. Today we have a mix of things. Some node servers have a node just for node server status, some mix the status in with the device nodes, some don't report status at all. In many cases, I've moved to not reporting status at all because what we have as node server status today isn't as useful as many think. It really only tracks the mqtt connection between the node server and PG3 (which is it's own thread in the node server) so everything else in the node server could be failing and your connection status would still be good.

If you want to make it a hard requirement, then yes. This is mostly just my opinion, but it seems like nodes are a representation of a device. If the device supports a heartbeat, then the node can also. Having a node represent the node server itself doesn't seem right to me. In general the node server should be invisible. In support of this, I look at how Insteon and z-wave are implemented and neither of those have "control" nodes that represent the controllers. I think of a node server as similar to a PLM or z-wave dongle just implemented in software vs. hardware. I know this isn't a perfect analogy but it seems pretty close. I know a node can represent anything and if we really want to create nodes that represent the node servers, then I think it should have a standard node definition and standardized driver types/command types and UOM's that are designed to represent that. One of the reasons I've been hesitant to create nodes for my node servers is because of nodes being a limited resource and using one just to report the status of my node server seemed like a waste of that resource. If this is no longer the case with IoP then I'm less opposed to these types of nodes.

Scroll down farther, you can select temperature in either F or C, just the C values come first in the list.

Then the ISY needs a way to accept a heartbeat.

I'm not saying that nothing will work. It depends on the node server design and what the node server author does with it. But because node servers are multi-threaded, it is very possible that one thread will crash while the thread that has the connection to PG3 continues and you'll never know that the node server isn't working. What we need is for something to independently monitor the process and report back to the ISY when a node server is not functioning, but the ISY doesn't have anyway to handle that yet.

That configuration looks ok to me. I can't actually get any data from your station with my token so I don't really know if it's OK on the WeatherFlow end.

Node servers are not required to have a node dedicated to providing node server status. Nor are node servers required to report node server status to the ISY. Node server status (as it has been typically done) doesn't even really make sense with PG3. If the node server dies or crashes, there isn't a running node server to report that fact. PG3 will only change the status if someone actually presses the button to start/stop the node server so if you're changing the status, you shouldn't need a notification to tell you that you changed the status. It is possible for a node server to configure PG3 to send connection status to one of it's node values. However, that is only tracking the connection status between the node server and PG3. It is possible (and probably likely) that a node server can fail while still remaining connected to PG3.

It works fine for me even with your station ID and the error is coming from WeatherFlow. So it has to be your configuration. The only error in the node server is because it's not getting valid data from the WeatherFlow server.

Something is wrong with the station ID. When the node server contacts the WeatherFlow server to get the information about the station, the WeatherFlow server is responding with: That is coming from WeatherFlow, not the node server.

If you ever ran version 3.0.39 of PG3, then the PG3 database got corrupted and that would cause problems with all of the node servers installed on it. But it shouldn't have removed any of the directories. The only time it should be removing the directory would be when deleting the node server or possibly when restoring from backup.

All values for every node are currently numbers. It's up to the UI to convert those to text based on the mapping provided by the node server. It's possible that there's something in the mapping that is causing UD mobile to fail, but I believe the admin console isn't having problems with it. If conditions are showing up as unknown, then WeatherFlow probably added some new ones that I don't know about. If they add something new, the mapping has to be updated so that the node server knows what to do with it. Yes, it takes a while for the forecasts to populate. There's something wrong in the node server and it ends up waiting for one LongPoll interval before it makes the query to WeatherFlow for that info.

You have the parameters in the wrong order for this command. Should be: sudo service isy status

Just pushed version 2.0.4 which I think will resolve the issue.

Looks like a bug in the unit of measure for PG3. It is reporting inches/day but saying mm/day. PG2 is reporting mm/day. .119 inches/day == 3.03 mm/day Will be fixed in the next version.

@macjeffThank you for all the detailed feedback. I can address some of now, and some of this on the list and will be address as time permits. Yes, agreed. As I posted somewhere else (earlier in this thread maybe), the migration process has not been worked on at all. The current PG3 releases have been mainly focus on allowing node server developers to port their node servers and not on all the features needed by normal users. This is good feedback. I'm not sure why installing would be slower, but I haven't tried to compare. I didn't think PG3 was doing anything differently from PG2 when installing a node server. But I can understand if the node server startup/initialization is slower. We've made changes to try and improve the process to make it more reliable and part of that is that there are now cases where some processes wait for others to complete so they can't corrupt each other which was a problem with PG2. This is supposed to be handled by the ISY software so it was removed from PG3. This wasn't a requirement for the Polyglot framework. It has been discussed but there isn't a clear path forward on how this can be implemented within the current framework. This is not likely to be something that will be in the initial release of PG3 if ever. There are some known issues with the store/portal authentication process. In order to access purchase information and make purchases, you need to be authenticated with the Portal. When you authenticate with the Portal the authentication is valid for about 1 hour and that authentication info is only held in memory for security reasons. There is a method to refresh the authentication automatically, which PG3 will do, but in most cases now, the refresh happens after it attempts to access the purchase info so that first attempt fails (which is why you see the message about failed to get purchase info). A refresh or resync after that should succeed. This will be improved, but right now, since it doesn't really effect functionality, it is lower priority.

Everything is being or will be looked at. It just takes time. I'm splitting my time between answering questions, resolving bugs and adding features to PG3. I appreciate all the the folks that are trying to migrate to PG3 as it helps immensely in finding existing issues, but it also means it's going to take some time to look into and resolve them all.

Ok, I understand. This is related to a bug in the ISY where the work-around is run a query. BTW, node server status is no longer true or false in PG3. It's connected, disconnected, and failed although I don't think most node server handle this correctly yet.

That's a known bug in PG3. The browser gets confused and needs a refresh/reload to show the correct data.

Most don't support query because the data is being polled at timed intervals, not by a manual query.

I'm sorry that there are so many issues with migrating from PG2 to PG3, but PG3 is not yet complete and there has been zero development effort to create a migration process at this point. A node server slot on the ISY can only be managed by one Polyglot and if something changes in the configuration of that slot, it can result in Polyglot thinking something else is managing it (i.e. marking it unmanaged). The process should work something like this: backup node servers with PG2. Results in a pg2_node_server_backup_file Stop PG2, PG2 is no longer going to manage the node servers. Restore the pg2_node_server_backup_file using PG3. PG3 will update the slots on the ISY to change management of those slots from PG2 to PG3. Review and possibly restart the node servers on PG3 This is how the process should work, but it may be broken/buggy at this point as it is untested. There is not yet any provision for migrating a single node server or maintaining a mix of PG2 and PG3 node servers. Because only one Polyglot can manage a slot and there isn't any way to migrate a single node server, the only current method is to delete the node server from PG2 (losing all nodes and programming). And then install/configure the node server on PG3 (and recreate any programming).

It only updates the forecast data every 5 minutes by default. Did you give it 5 minutes to pull data the first time?