bpwwer

The hub seconds since seen is how many seconds it's been since the hub sent data to the plug-in. 165469 translates to about 45 hours since the plug-in has seen any data from the hub. When things are operating normally, the hub should be sending out data packets about once a minute so that number should never be above 120 unless something is wrong.

This plug-in connects up to a BambuLab 3D printer to monitor status and control the printer. It is also able to detect AMS units and display some information about them. Below is a screen shot of the main node for an A1-mini. The printer will send out status updates at ~1 second intervals. One use case for this would be to monitor the time remaining or percent done of a print job and send a notification when a specific condition is met. I.E. if Percent Done is 50% send notification for job is half way done. You can also control the printer to some extent.

Looks like the upgrade replaced my user account on the Polisy with a udx_installer account. At least it didn't delete my home directory. Now I get to create a new account and move everything from the old account to the new account.

Based on what you've reported, I'd say the most likely answer is that the Admin Console has a bug and always displays "AM" for the start time. There's a very small possibility that if the hardware real-time clock is 12 hours off from actual time and IoX somehow is using that when the internet is down (vs. using the system software real-time clock), that when it sees a 12 hour time change, it crashes. However, from what I've been able to find, FreeBSD is supposed to keep the hardware clock synchronized with NTP so it should never be that far off. But maybe there's a hardware issue with the real-time clock that prevents it from being updated. What do you get if you run sysctl machdep | grep rtc If machdep.disable_rtc_set is set to 1, it disables updating the hardware clock.

@WSommerfeld, Added type 6 and pushed the update to the plug-in store. It's now version 1.0.4

Sure, it can be added. Are you sure it's not more like RGBWSTRIP (type 37)? Can you try setting that to 6 and see if it works?

While I haven't had this specific issue, I have had some very strange issues with my Polisy. At one time IoX would randomly start dumping a log message continuously until it filled up the disk and then things would start failing. Clearing the log file and restarting the system would resolve it for a few days and then it would happen again. I don't have that issue anymore so it must have been an update that fixed it, but no root cause was ever found. Given the amount of debug you've already put into this I would think the next steps would be to determine if it is something in the OS or hardware. I know it's not easy, but backing up your stuff and then restoring on new hardware or re-imaging your Polisy and restoring seems like a reasonable next step.

No, it just builds nodes for each sensor it finds in the data from Emporia. You can delete the nodes from the admin console, but the plug-in will re-create them the next time it restarts.

Unfortunately, because of the way Python works (and Python is what most plug-in's are written in), it sometimes needs things that are part of the development packages on the Polisy/eisy. Most Python packages are available for the OS that the Polisy/eisy is built on in ready to be used form, but some are not and typically are available in source only form. When they are only available in source form, they need to be compiled on the Polisy/eisy to be used. To compile them, we need the compilers installed and they only get installed if you install the dev packages.

The displayed uptime is pulled from PG3x when the browser application starts. Once it's running, it just keeps the time updated without querying PG3x all the time. So if you restart (or reboot the system) you also need to re-load the browser application to reset the uptime counter to the current PG3x uptime.

did you you install the dev packages on the IoX? Some of the modules need stuff from there to work.

@tmorse305 I looked over the code and it looks like that happens when the plug-in starts? When the login to the Emporia servers fails, it throws the error but then continues to try and discover devices, which also fails, throwing the second error. At that point the plug-in basically stops. I can make some changes to have the login attempt loop until it succeeds, that might help some. But I also don't see anything in the library code to re-login if queries fail so I think that's going to cause similar problems where the plug-in may just fail to query until it's restarted. I can add some checks to try and detect query failures, but that's one of those things that hard to test without there being actual failures.

I don't know. He hasn't made any changes to it since I ported it to PG3.

I've pushed out a new version, but I can't update the store entry. However, you should be able to go to the store and install/re-install it and it will install the new version (3.0.1).

From what I can tell, the plug-in never actually updated the temperature values. It would get the current values when the plug-in starts but then never updates them. It did get updates for the pucks and vents (but not the rooms) and would update some of the other values like rssi from the update. I think I have it mostly working now but since I don't own the plug-in, I'll have to see what i can do to get it updated in the store.