bpwwer

No, no correlation to the LiFX problem. I understand the frustration. The fact some of them are working is actually a good sign, it means it can work, we just need to figure out why it's not working for all of them. The node server log with debug enabled is the most important piece of information to understanding what is happening and you still haven't provided that. Without getting into to too many technical details, when PG3(x) installs a node server and the node server creates nodes, there are two main parts to this. The node server running on PG3(x) creates the node in the IoX. Updates to that node come from the node server and commands to that node go to node server. So both the node server and the IoX have an internal representation of the node. Some of the synchronization of this is managed by the node server and some by you the user. The Discover button (and the configuration) on the node server is how it determines what MH devices are out there. If it sees a new device, it creates a new node on the IoX. However, the opposite isn't true, it doesn't remove the node from the IoX if it doesn't see the device during the discovery. That's where you would have to manually remove the node to keep things in sync. That's why the IoX may show 10 device nodes, but if the node server only discovers 4 you get 4 working and 6 not working. The discovery process isn't perfect, it depends on a number of factors both in how the devices themselves are designed, how busy the network is at any given time, etc. It something like asking a group of people to say they're name to see who is there. They start talking over each other and you may only be able to catch a few of the names. That's why you can also enter the devices in a list on the configuration page. So I'll re-iterate, the node server debug log is how we determine what the node server is doing and manually configuring the devices in the node server may help. Those two things are how we move forward.

when the right versions of the libraries are installed, the node server works. Getting the right versions installed when things seem to change daily on the system is the challenge.

@SteveBLEach slot on the dashboard display is a different node server. Slot one holds the Elk node server and now slot 3 holds the ISY Portal node server. There can be up to 100 different node servers installed on the IoX. The ISY Portal node server is something separate from PG3, and not managed by PG3 but rather it is managed by the ISY Portal. That's why it shows up as unmanaged in PG3.

Do you mean they all populated after 7 minutes or that you had to manually query them to get them to populate? In general, you shouldn't need to manually query to get them to populate. However, because of how node servers work and timing, it is possible that some initial values could be lost on startup and that the node server could take quite a while before it sends updates for some values. For example, WeatherFlow will send all of the weather values when it starts. If it sends those before the IoX is ready to receive them, it won't re-try until it has a new value to send. For things like wind speed, that could be in 60 seconds, but temperature could be 5 or 10 minutes. So it would slowly populate those values over time. For some of the weather service node servers, it can be 30 minutes before it gets an update. It's going to depend on how often the node server sends updated values.

I see some of the problem. When you run discover on the node server, it tries to discover all of your bults/strips. For the devices it finds, it adds to it's internal list. It will then create nodes for any new bulbs/strips that it discovers. However, it doesn't delete nodes that were found at one time but not found with the current scan. This means that the list of nodes in the AC may not represent the list of nodes that the node servers is currently communicating with. The nodes that aren't showing status aren't in the internal list which is why it reports not found when you try to control them. The question is why isn't it discovering all the devices? I don't know. But you do have the option of manually adding them to the node server via the configuration screen. That may solve the problem or, if it really can't communicate with the device, you'll just get a different error, instead of not found, it will be a failed communication error. But it's worth a try.

Probably not. The node server log doesn't really show historic log entries (unless you download it) and the PG3x log won't maintain that level, it will revert to info on restart.

No, 2.1.23 is still in release testing and nothing in that would be related to this issue. Can you check the node server log (dashboard -> MagicHome details -> log and set that one to debug. Try the on/off commands again and either post the results of that log or download a log package an PM it to me.

Possibly, PG3x is more dependent on IoX and UDX so issues with those can impact PG3x. If you do see the issue with the nodes not populating try the following: 1. Set one of the node servers that isn't populating to debug log (if WeatherFlow is one, it's a good one to check) and monitor. If it's sending updates to PG3x it should be obvious. If not, you'll likely see very little log activity. 2. If you see it sending to PG3x, open the PG3x log and set it to debug. You should see the http requests to IoX with status 200, meaning it was able to send the update to the IoX. If not, copy a couple of entries and post here. 3. Open the event viewer on admin console and set to level 3. You should see related entries for each request sent by PG3x. Based on what the results are for each step, we can narrow down where the problem is happening.

3.1.18 hasn't been released to production yet so if 3.1.16 is working then no PG3 upgrade is needed at this time.

I'm far from an expert on MH devices/app. I did create the current node server and like I said, it has been working well for me with the the 2 lights that I have. Have you looked at the node server's log file? It can provide a lot of information about what the node server is doing and whether or not it is even able to communicate with the devices. For example, in debug mode, I'll get these messages every few seconds as it checks the status of the lights: 2023-02-17 16:12:03,363 Thread-21705 udi_interface DEBUG rgbled:watcher: 70039f051de9: status 81 35 24 61 01 1E 00 00 00 00 07 FF 0F 6F 2023-02-17 16:12:03,364 Thread-21705 udi_interface DEBUG rgbled:levelOf: levelOf input: 0 0 0 2023-02-17 16:12:03,365 Thread-21705 udi_interface.node DEBUG node:setDriver: 70039f051de9:mh 192 168 92 94 No change in ST's value 2023-02-17 16:12:03,366 Thread-21705 udi_interface.node DEBUG node:setDriver: 70039f051de9:mh 192 168 92 94 No change in GV1's value 2023-02-17 16:12:03,367 Thread-21705 udi_interface.node DEBUG node:setDriver: 70039f051de9:mh 192 168 92 94 No change in GV2's value 2023-02-17 16:12:03,367 Thread-21705 udi_interface.node DEBUG node:setDriver: 70039f051de9:mh 192 168 92 94 No change in GV3's value So I know it's communicating with the lights.

Hmm, that's not what Michel said when I asked him what reboot meant, he claimed it was a restart of the isy service. I've been trying both and so far I've not seen any issues with WeatherFlow reporting data or the admin console displaying the data after either type of reboot. It is possible to trace the flow of data from the node server to the IoX using the PG3(x) log files. The log levels needs to be set to debug to do this. The node server log will report every time the node servers sends an update to PG3(x) The PG3(x) log will report every time it sends an update to IoX and will also show if it was successfully sent or not. The more node servers that are running the more difficult it is to trace, but since WeatherFlow should be reporting data every 60 seconds it's not too bad: For example, WeatherFlow node server reports 2023-02-17 15:59:08,766 MQTT udi_interface.interface INFO interface:_message: Successfully set 240018 :: WINDDIR to 2 UOM 76 then the PG3 log shows 2/17/2023, 15:59:08 [pg3] debug: ISY Response: [Try: 1] [00:21:b9:02:61:f1] :: [200] :: 0.935454ms http://127.0.0.1:8080/rest/ns/1/nodes/n001_240018/report/status/WINDDIR/2/76 2/17/2023, 15:59:08 [pg3] debug: MQTT Results: [ns/status/00:21:b9:02:61:f1,1] :: {"set"[{"address":240018,"driver":"WINDDIR","value":"2","uom":76}]} 2/17/2023, 15:59:08 [pg3] debug: [PUBLISH: udi/pg3/ns/clients/00:21:b9:02:61:f1_1] {"set":[{"address":240018,"driver":"WINDDIR","value":"2","uom":76}]} The first line says it sent it to the ISY and was successful (status 200). The second line is the results back to the node server, and the third line is it actually sending the results to the node server.

@DennisCI've seen your ticket, your problem seems different as the node servers are starting. I'm trying to reproduce and does "reboot" mean a system reboot or an IoX reboot?

Roku node server version 2.0.5 should fix the errors

Which platform and what version of PG3? The latest versions are: eisy: PG3x 3.1.22 polisy: PG3 3.1.17 The initial release of PG3x for eisy had a bug that would prevent all node servers from starting but that has been fixed in the later releases.

I have a couple of Triathalon honeycomb shades. Initially, I had them controlled only by a Pico and that worked very well. After getting a Caseta SmartBridge and re-writing the node server for it, it is also controllable via that. However, that being said, I have them set to open at sunrise and close at sunset (via the SmartBridge) and almost never do anything else to control them. Because I have the smartbridge at the opposite end of house from the shades, every one in while, it will fail to control one of the shades and I have to hit the Pico to operate it. I'm not sure if there are limits to which shades work with which protocols as I only have Caseta compatible devices. At some point I plan to get some RA3 devices and controller, but haven't yet.

@MJsan I haven't had any problems with the MagicHome node server but I only have 2 lights set up. Node servers and PG3 both maintain log files that can provide a lot of information that will help with troubleshooting problems. I suspect that if you look in the node server log, you'll see that for the lights that aren't working, the node server says it can't connect to them. From my (granted, very limited) experience, it seems like the cloud connection is much more stable than local connections which is why the app always seems to work.

@garybixlerI'm not sure what you're asking. PG3(x) uses MQTT for communication between the PG3(x) components, not for communication with external devices. A node server is needed to create a communication bridge to external devices.

@MrBill, thanks for the correction.

It's not a problem with the credentials. If you were using the wrong credentials you'd get a "401 Unauthorized" error. The problem is that PG3x is unable to contact the UDX service. The UDX service is what does the authentication and is a separate service (that is supposed to be) running on the eisy. I'm not able to debug issues with the UDX service so your best bet is to submit a support ticket.

For the ecowitt ${sys.node.node003_wh31_3.name} Temperature: ${sys.node.node003_wh31_3.ST}F Humidity: ${sys.node.node003_wh31_3CLIHUM}

It's in release testing. The update check isn't very smart and can't tell the difference between being in release testing (which is brand new for UDI) and production. Once it passes release testing, it will be moved to production and a release announcement will be posted.

The "Unknown Error" happens PG3x is unable to connect to the UDX service to authenticate. This can happen if the UDX service is upgrading or if the UDX service isn't running.

That means that PG3 isn't running. If a reboot of the Polisy doesn't fix it, then there's something wrong on your system that is preventing PG3 from starting. You can try doing an "Upgrade Packages" again, followed by a system reboot and see if that helps. If not, you'll have to submit a support ticket.

You need to specify if you're using PG3 on a Polisy or PG3x on an eisy. There are significant differences in how each behave at startup. If you're getting a site not found error and nothing shows up, then PG3(x) isn't running. PG3(x) is the server that serves the web pages to the browser. If it isn't running then there are no pages to be served. Typical reasons why it's not running would be because it was never started (UDX is supposed to start it) or it crashed on startup or it can't find the IoX or UDX isn't running. In most cases, a restart of the device will correct any of the above. If you're getting the log in page, but it won't let you log in For PG3, that would imply the wrong credentials. The PG3 login authenticates against what's in the PG3 database. For PG3x, it could mean that UDX isn't running as it uses the IoX credentials and authenticates them using UDX. Or that the credentials being used are wrong. The error message will usually indicate which one it is.

the mongo package was causing problems for UDX and since everything depends on UDX, nothing would work.