bpwwer

Probably everyone. PG3x has a bug that's preventing backup from working.

Not having a log available is a good indication that the node server is crashing on startup. In most cases, this would be because it didn't get installed correctly or something it needs is missing. I'd suggest that you try re-installing the node server (node server store -> select YoLink -> click the install button -> select the re-install to existing slot option. If that doesn't allow it to start, download the PG3-log package and attach it here. Also, including the time of day when you did the re-install will help when looking at the log to narrow down what part of the lot to look at.

No, beyond just that increasing the log level results in more log info. If set to Critical, you'll probably see nothing, ever. I'm not sure if there are any messages at that level. If there are, it is very few. error and warning are just as they say. Error messages and/or warning messages only are output to the log. info are messages that report what PG3 is doing. This is the default and generally provides enough information to figure out what PG3 is doing at any given time. debug provides even more detail on what is happening. It tends to be used for things that might be nice to see when debugging but generate so much log output that it can make the log harder to read. db operations adds all the reads/writes to the PG3 database into the log. This generates a huge amount of log info and is only going to be useful when trying to track what is being read or written from/to the database. In general, there's no real reason to change from the default unless you're working with support and they request that you do so.

There isn't yet a migration process to migrate from a Polisy to an eisy. That feature is not yet in the PG3 version included with the eisy. The initial release was designed to be setup as a new system, not replace an existing system. The ability to restore a PG3 backup and migrate nodes/licenses is currently my highest priority. PG3 not recognizing the local IoX sounds like a bug. If it's not allowing you to add it, that probably means it is already in the database and you can't have duplicate entries in the database. It is just that the UI is not able to get that records from PG3.

No, I don't have any type of Davis system and these were written based on requirements and requests from others. Any updates would need to include documentation for those updates. I'm time limited right now so updates would be a pretty low priority. They weren't really meant to be used together, I didn't realize it would even make sense to use both. My understanding was that they were different API's for different Davis stations. I believe that's because it can report some data in either metric or imperial and other data in only imperial. The node server isn't doing any conversions. That would be a typo (or mistake) I start with an existing node server and modify it to work for another, in this case I started with the Open Weather Map node server and forgot to change that in the instructions.

The eisy creates self signed certificates and uses those to both authenticate and encrypt communication between the various software components on the box. Because most users have the box behind a router with no public IP address, it's very difficult to create certificates signed by an authoritative CA. If you tried to install your own certificates in place of the UDI self signed ones, you'd have make sure covered all the components or things would stop working. It's not impossible, but it's not documented nor is it currently supported by UDI.

The eisy is supposed to manage all of the certificates it needs internally. If you want the UI to access PG3 with https, you have to trust the UDI self-signed certificate. The alternative is to use http to access the UI which will then do so without any ssl encryption.

I believe a number of people have documented what they did to migrate from PG2 to PG3. At this point, most PG3 versions of the node servers have continued to get updated while the PG2 versions have not, I'd recommend just deleting the PG2 version and installing the PG3 version. You can try the PG3 re-install option but then you run the risk of the PG2 version causing issues later. When you configure PG3 with the ISY994 it should show all the PG2 node servers as unmanages (because PG2 is currently managing them). One-by-one. 1. document the configuration in PG2 (screen shot of config page, cut-n-paste values, write them down, whatever). Then delete the node server from PG2. 2. Within a few minutes, PG3 should then show that slot as empty. Install the PG3 version to the same slot and then using the configuration info you saved above, re-configure it. Your PG3 version is only one minor version out of date. 3.1.15 is stable and should be fine for now. When you're no longer using PG2, you should be able to an 'update packages' to update to the latest versions. No re-flashing necessary. I believe the only thing missing with IoP 5.4.5 is the ZMatter board support so you'll have to update the packages before you want to migrate your z-wave anyway. The main thing to finish is the getting PG2 migrated to PG3 before upgrading.

PG3 uses 1888, PG2 uses 1883. Different ports so they don't conflict with each other. mqctrl is a node name (or address). It is a node created by the node server. The log entry is just saying that when the node server started, it PG3 didn't find an existing node called mqctrl in it's database. This will always be the case when a node server first starts, none of it's nodes will be in the PG3 database. It's a warning mostly to the node server developer. We used to get the node server version from a file but now expect the node server to handle it internally. This node server is still getting the node server version from the file. Yes, the node server started correctly but then was unable to connect to a broker. It has nothing to do with the internal broker that PG3 is running. There needs to be another generic broker running somewhere that the node server can connect to. I'm not familiar with the mqtt-poly nod server so I'm mostly guessing that it needs a generic broker running. I know it won't work with the PG3 internal broker since that has authentication requirements that the node server won't know. I'm not sure about the PG2 internal broker and it's relationship with the mqtt-poly node server. The OS doesn't make difference but the version of PG3 might. The ability to restore PG2 backups on PG3 was somewhat supported with the initial PG3 production versions but because of the licensing requirements for PG3 node servers, it's probably not going to work for current PG3 production versions.

I can provide a bit of clarity on the commands above and for the most part they look correct. cp /dev/null ${PREFIX}/pwfile This is simply making sure the pwfile is empty. It is overwriting whatever was in pwfile with nothing (/dev/null) sysrc mosquitto_enable=YES This is enabling the mosquitto service so that it starts up automatically whenever the Polisy is rebooted. You see two process id's when you grep for mosquitto because one is the mosquitto process and the other is the grep process itself. So that is normal. Even though both PG2 and PG3 have internal MQTT brokers, they aren't usable for anything other than PG2 and PG3 communication with node servers. They're not general purpose MQTT brokers. Running Mosquitto in addition should be fine as long as the port is different and 1884 is not used by either PG2 or PG3 and should be fine. The Mosquitto settings look correct and shouldn't effect either PG2 or PG3. And it definitely shouldn't have any effect on IoX showing up in the finder. If you upgraded packages, that may be the issue now. There have been issues with the latest updates, I'm not sure of the current status and if all the issues are resolved or not. I'd suggest doing another upgrade and see if that helps the finder pick up the IoX. I'm also concerned that by upgrading packages you may have now removed PG2. I believe @Michel Kohanimhas removed PG2 packages now and if that's the case, then you're going to have to start over and get migrated to PG3 before upgrading any packages. I.E. re-flash install mosquitto per above restore PG2 from backup migrate what's on PG2 to PG3 and make sure things are working. Then upgrade packages to get the latest IoX and PG3 installed.

There are a number of things that went badly here. First, this probably isn't obvious but when you re-flash the SSD, you're are basically factory resetting the Polisy. Before doing this you should make a IoX backup and a PG3 (and PG2 if it's being used) backup. You don't say what you had backed up and what you restored (if anything). The first step after flashing the SSD should have been to restore the IoX and then restore PG3 (and PG2). In theory, that should have brought everything back to the state it was before the re-flash. Your description above doesn't provide any details on what steps you took here (maybe that's in the other thread?) But based on the fact that PG3 was showing unmanaged, it sounds like you didn't restore PG3 from a backup. Both PG2 and PG3 run internal MQTT brokers. I believe that PG2 actually runs it's internal broker on the standard MQTT port so installing Mosquitto would probably conflict with it unless you specifically started it using a different port. If Mosquitto was started before PG2, it would block PG2 and nothing in PG2 would work right. Which is that looks like is happening based on the log information. Now this also assumes that the image you flashed doesn't already have Mosquitto configured. For the eisy, we've started moving to using Mosquitto for the PG3 broker instead of the internal broker. The image may have that already enabled to prepare for the migration to PG3x. I don't really know how @xKing's node server expects for MQTT broker configuration so I'm mostly just guessing that it may be conflicting.

You'll have to restore a PG2 backup to get the node server's back. Unmanaged means PG2 sees the node servers installed on the i994 but it doesn't know anything about them.

The error message means there's a browser running the UI that is not longer authorized to connect to PG3, but continues to try. The connection between the UI running on the browser and PG3 is only good for about a week and and then it expires. When it expires you need to log out and log back in to the UI (and maybe reload the page in the browser). I see this a lot because I'll sometimes have multiple tabs open to PG3 and forget about one. That one will expire (or I'll restart PG3) and the forgotten tab will keep trying to communicate with PG3 and get rejected with that error.

It failed to build one of the dependencies it needs to run. This was while trying to build the pycryptodome 3.3.1 library. cc -pthread -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -fPIC -DLTC_NO_ASM -Isrc/ -I/usr/local/include/python3.9 -c src/MD2.c -o build/temp.freebsd-13.1-RELEASE-p5-amd64-cpython-39/src/MD2.o In file included from src/MD2.c:28: src/pycrypto_common.h:47:10: fatal error: 'stdint.h' file not found #include <stdint.h> ^~~~~~~~~~ 1 error generated. error: command '/usr/bin/cc' failed with exit code 1 [end of output] I suspect that a package is missing on your Polisy that would allow this to build. @Michel Kohanimdo you know which package is needed for this and can it be added to the list of packages that must be installed?

There is also the Eagle-200 (Rainforest Gateway) device that can connect to smart meters and there is a node server for it as well. If I recall correctly, this pulls data from the device locally instead of from the cloud.

PG3 can be restarted using the shell: sudo service pg3 restart So that assumes you have a way ssh to the Polisy remotely. With the current version of PG3 there isn't any way to restart node servers other than through the PG3 UI.

@TJF1960I'm not able to really debug issues with upgrades. I just make the new PG3 packages available. I know there has been a lot of issues with the upgrade process. Both of my Polisy's hung while trying to update and required manual intervention to get them working. I had to ssh into the Polisy and run 'sudo pkg install -r udi pkg' as reported elsewhere and that seemed to get it unstuck and it then finished the update. There may be a more official fix, but I'm not aware of it at this time.

My Magic home lights got into a state last night where they were controllable from the Magic home app but I was getting failed connection from the node server. It seemed to be something wrong with the lights themselves as I had to power cycle the lights to get them to work from both the cloud and locally. You might want to see if the Govee lights work with the MagicHome app and if so, if they can work both with the cloud and locally. If they can be configured to work locally, then they should work with the node server.

@sjenkinsYou should be able to do re-installs via the node server store, select the node server, select install for the purchase option and then you have the option to re-install to the same slot it is currently installed in. From the purchases page, it tries to guess what you would select in the last step above and will fail a lot of time. 3.1.16 changes the re-install on the purchases page to follow the same steps as the process from the node server store.

Your current installation of Kasa is too old to support automatic updates. The information needed for PG3 to determine what you purchased didn't exist when you did the initial install of Kasa. You need to either upgrade PG3 to 3.1.16 which will then allow you to re-install from the purchase page or go through the node server store and re-install the node server that way. In either case, you'll need to select the proper install option and re-install. A re-install will keep all your current configuration and nodes so you won't lose anything by re-installing.

No, it's up to the node server developer to determine how it is handled. It varies for a couple of reasons: 1) PG2 forced the node server to manage the connection state, while PG3 handles that internally. So PG2 node servers that were ported without making any changes here will continue to try and manage it themselves and are probably only partially effective at it (like WeatherFlow) 2) The ability to configure PG3 to report the connection status to a specific node/driver was added after a number of node servers had already been ported and not all authors have gone back and updated the node server to take advantage of this. I'm certainly guilty of #2 as I ported a lot of node servers over early. As I make updates, I try to remember to make that change as well.

Are you PG3 3.1.16 or something a little older? Starting with 3.1.16, the re-install from the purchase page and the store should work exactly the same. Prior versions would fail from the purchase page if it didn't know which purchase option you had originally made. When the ability to support multiple versions of a node server was introduced, it made it difficult for PG3 to determine which version had been installed previously. The result is that things like auto-update can't always figure out what version should be used to update. When you do a re-install, you have to manually select which version to install so there's no guesswork on PG3's part. In your case, it looks like the auto update failed because something was modified in the node server directory that cause the deploy method to fail. That's probably a node server issue if it is modifying files that shouldn't be modified.

Some node servers set up a status value that tracks the status of the connection between the node server and PG3. So when the connect is stopped, PG3 should send a update to the ISY/IoP with updated status. But not all. WeatherFlow sets the status as on-line when it starts but doesn't send any updates when it is stopped. It was written before PG3 was updated with the ability to automatically track the connection status.

I don't think deleting and installing will do anything unless it's just configured wrong. Are you sure it's getting data from the Ambient network? They're not known for their reliability. Switching the node server to debug level logging may provide more information than what was in the log you attached earlier.

There are no errors being reported for the Ambient node server in either log. From what is is in the logs, everything appears normal and working correctly.