bpwwer

@elliott9 Looks like you know a fair amount about unix like systems and how to poke around them. UDI as a couple of applications that run and manage things. You can check the log files for these. /var/udx/logs/log /var/udx/logs/debug.log This service is what actually manages the updates. If it had issues, it can leave things is a state where stuff just doesn't work. In some cases, re-booting multiple times can get it to clean things up. /var/isy/FILES/LOG is where the IoX log files are located. There are a number of them. One of these may help determine what's wrong.

A PG3x backup can be directly restored. The migrate from PG3 is only if the backup was made using PG3 (not PG3x). PG3x and PG3 use different formats for the backup, thus the reason for the migrate from PG3 option to exist.

I don't use the plug-in because all I needed was to to turn it on a few hours before we leave to go there. So far (only have used it once) it is working as intended. I don't believe there's any way to get status of the fireplace, but I believe that's because the fireplace can't provide any. Would need an external thermostat (like what you have) to monitor temperature. I should probably add a temperature sensor and do more integration.

Look at the Bond Bridge (yes, there is a Plug-in for it). I just installed one of those for our gas fireplace at or cabin. It doesn't replace everything the remote can do since it doesn't have a temperature sensor so it can't act as a thermostat. But being able to turn it one a few hours before we head out there makes it so we can arrive to reasonably warm cabin instead of waiting 6 hours for it to heat up.

I don't really know anything about it. I ported it from PG2 to PG3, but the original author took ownership after that. @automationgeek are you still maintaining it?

I ordered a couple of devices and started on a plug-in for it. They seem to have a lot of different devices so I'm not sure how many of those can be supported. Basic switch/plug are pretty easy but the garage door kits and various thermostats are a bit more effort.

Looks like there's a python library available -- https://github.com/albertogeniola/MerossIot so creating a PG3x plug-in should be possible without too much trouble. It would be a fair amount of work since it would have to support a few different device types. I'm estimating a week or two to get something usable. The biggest question is how much of a demand is there. They do have quite a variety of device types so getting them all supported by a plug-in would be quite a lot of work. At least they don't see all that expensive. It also looks like they are able to work with Matter so assuming the devices you have work with Matter, it may make more sense to just wait for UDI to get Matter support working and supporting them.

No question that the branding/documentation needs work. For many years, the emphasis has been on getting things functional and stable with the limited resources available. UDI products consist of a hardware/software solution and a lot of the terminology gets intermixed. But there are really 3 distinct solutions: 1) ISYi994 family of devices. This was micro-controller based solution running custom firmware designed to support primarily Insteon and Z-wave devices. Commonly referred to as an ISY 2) Polisy family of devices. This was the first generation built on a general purpose platform. It is a small computer running custom software created by UDI. The software component is typically called IoX. IoX is a re-write of the custom firmware for the ISY so that it can run on a normal computing platform. 3) eisy family of devices. This is the second generation of the hardware platform. It is again, a general purpose computer but is faster and more capable than the Polisy platform. It runs the IoX software component. The IoX component continues to support Insteon and Z-wave devices and has continued to expand to include zigbee and matter. The last major iteration of the ISY firmware and all versions of IoX also support the ability to support additional types of devices through the use of a plug-in/integration architecture known collectively as polyglot. The current polyglot release is called PG3x. The polyglot instance (or PG3x) is a software component that runs on either a Polisy platform or an eisy platform and integrates with IoX. PG3x provides the plug-in store where you can get/purchase support for additional devices and device types beyond what is included in the IoX software. A large number of these plug-ins are written and maintained by third parties, not UDI. A long term goal is to combine IoX and PG3x into a single, fully integrated software stack. In addition to the above, there's also a software component called the Admin Console, which is written in Java and designed to provide a user interface for the ISY firmware and IoX software. A recent announce indicated that a new version of the Admin Console that is written as a web application will be available soon, removing the dependency on Java. This new user interface application is possibly built off the work done to create the IOS and Android UD Mobile application.

So there's no misunderstandings, UDI wanted to add support for RA3, but Lutron would not provide the protocol specification. The support that exists today is based on the work someone did to reverse engineer the protocol.

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.

@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.