bpwwer

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.

@DHemrick02 I'm taking a look at it and I don't really see anything that looks wrong. However, it does look like the code is designed to only trigger a temperature change on 1 degree Celsius changes. This may account for some/all of the issues you're seeing. The temperatures are in C and get converted to F in the plug-in. So anything between 17.0 to 17.99 C will get converted to 62.6F. If it was doing the conversion properly, you'd see values between 62.6 and 64.4F Also, it's not yet clear to me how often the pucks (and vents, etc.) report updated values to the server. Some info I found on-line indicates that the puck display will only update if the temperature changes is greater than 1.1C (2F) and it does this to reduce internet traffic. How updating the display is related to internet traffic is unclear. Possibly that really means that it doesn't send updates to the server. If that's the case, then you'll never be able to get good real-time data from these things. https://support.flair.co/hc/en-us/articles/360049596711-Why-is-the-temperature-on-the-Puck-different-than-the-Flair-app I'm going to send you PM with some additional information.

Chris also owns 25957. Anything z-wave related has likely been assigned to Chris. I don't know why he hasn't responded to any of them but hopefully there'll be an update after Monday.

PG3 had the ability to read a PG2 backup file and attempt to migrate PG2 plug-ins to PG3, but it would only work in a few cases. PG3x only has the ability to migrate plug-ins from PG3. PG2 was EOL'd before PG3x was available so no effort was made to migrate from a system that had been EOL'd for a while.

I'm not sure I should reply to this or not, but I'll risk it. I'm not representing UDI and I'm also not very familiar with z-wave devices in general. However, if I understand your ticket, I think the issue is really on the HomeAssistant side of things. The eisy has the concepts of control and status. Those are separate things. Control is an action (I.E. pressing a button) while status is a state (I.E. on/off). From your ticket it sounds like eisy is correctly identifying those. When you press the button there is a control action of ON. You should be able to create an eisy program something like if control scene buttn x sends on do something. This program would run anytime you pressed the button. The eisy also changes the status/state to ON. No matter how many times you press the button , that status/state does not change so nothing that is triggered on that state change will happen. This includes HomeAssistant, which appears to only be triggering on a status/state change. If HomeAssistant would/could also respond to the control action, it would likely work as you want. My personal opinion is that scene buttons like that should not have a status/state because it's confusing and there's no way to handle well. If anything, buttons like that should have a "pressed" and "released" states as that more closes matches what's really happening with things like scene buttons (or really buttons in general). Status/state should be used for devices that actually have a state, like a light or relay. I can't help at all with your second ticket. Both seem to assigned to the right person but I don't know why he hasn't responded to the tickets.

That's going to depend on where each service is getting the data for your location. Chances are pretty good that neither will be all that good as they tend to get data from airports. Unless you live next to an airport that is providing data it will probably not reflect what is happen at your location. However, none of the weather service data provides are very transparent about where the data comes from so you may get lucky and one of them is getting data from a weather station close by. If you really want accurate data for your location, your best bet is to get a personal weather station and use that data.

As others have mentioned, the short answer is yes. There are a number of plug-ins that make use of USB->RS232 interfaces to control devices; Russound RNET and the two USB relay modules are the ones I'm familiar with. However, those plug-in are all written for the specific command set of the device they are trying to control. There isn't a generic USB<->RS232 plug-in that you could use to control HomeWorks. I do have plug-ins for Lutron Caseta (and RA3) and RA2. I can't imagine that the HomeWorks command set is all that different. It may be possible to use the LutronRA2 plug-in with a USB to serial adapter connected to a HomeWorks controller. It would be an interesting experiment anyways.

Thanks for verifying!

Pushed version 1.0.1 with the fix.

Of course the data being sent would be different from what they document. Why would I expect their documents to be right [he said with much sarcasm]. It's an easy fix, I'll have it done shortly.

Next release - version 2.0.13 has been published to the plug-in store.

Nevermind, the raw data was in the attached lot in the first post. It looks like they added aqi data (named aqi_pm25), which matched the PM 2.5 sensor in the plug-in's parser. Should be fixed in the next release.