bpwwer

@tlightne You can set the log level to debug and check what data is coming from the console to see if it is there. However, both plug-ins use the same code to parse the incoming data and create nodes and values. The only difference is how it access the data. So if it's not showing up, it's most likely that the console is not sending it.

I finally figured out the magic last night so I'm now able to discover the devices and get nodes configured. Once I get this all cleaned up, I'll publish a beta release. The beta will dump a bunch of data in the log for each device it doesn't know about, I can then use that data to add the code to create nodes for those devices. I don't think any of your devices will create nodes unless I make some guesses about the plugs and right now only the MSS115 plugs are "known" to the plug-in. With the basics working, it should be pretty easy to add new device types.

My hub is a msh300hk, it came with the ms200 door/window sensor. My understanding is that the various sensors (door/window, leak, smoke, temp/humidity) need to pair with a hub to work. The plugs/switches are all standalone devices. I've made a bit of progress and I believe I understand better how they work, but I'm still not able to get some of the important parts of the API to work. If I use just the local HTTP interface on the devices, things seem to work mostly as expected. However, based on some stuff I've read, new firmware versions may require additional changes to work with the local interface. To use this, the plug-in user would have to configure the plug-in with the names and IP addresses of the devices since there's no discovery method. I am able to query the Meross servers and get a list of devices associated with the user's account. In theory, this would allow discovery of the devices without having to configure anything. But the information about the devices doesn't include the IP address so I can't make use of the local HTTP interface. When I try to use the Meross servers to get additional information about the devices (which would include the IP address), they ignore me and don't send anything back. However, I am able to send commands to turn the plugs on/off. So it's a bit strange that I can send commands to control the device, but the commands to query the device information/state seem to fail. What I'd like to use is a combination of methods so that I can auto-discover the devices and then send commands through the local interface. Another issue I'm going to have is dealing with other devices. Their data structures aren't easy to work with. For example, instead of providing a list of sensors with the sensor type embedded in the list like this: [sensor_type: door/window, state: open] [sensor_type: smoke, state: off] [sensor_type: temperature, state: 79] They do this: [doorwindow: {onoff: 1, online: 1}] [smoke: {}] [temperature: {value: 79}] So I have know what the sensor names are before I can parse the info about them. Without documentation, it will take folks using the plug-in to determine what the device data looks like before I can update the plug-in to support the devices.

@MBrzeski I found the problem and have released a new version - 1.0.1 with the fix. You'll have to restart the admin console after updating the plug-in so that it picks up the changes. Thanks for reporting the issue.

I don't use HomeKit but the hub for the door/window sensor needed to be added that way. When I tried to add the plugs, it said it needed a AppleTV or something but I don't have that set up either. I finally got the plugs added. I had to hold the on/off button for something like 30 seconds and then it worked. Every other attempt, even though the lights were flashing in the manner it said was waiting to add, failed. I'm not sure what the problem is, but I'm having pretty major issues with the hub. When I query it via the local http interface, the response time varies from about 1 second to 40+ seconds to no response it all. When I connect to the Meross MQTT server, it still takes a couple of seconds to send out messages related to the door/window sensor state and the hub seems to loose it's connection frequently resulting in missed state changes. I haven't played around with the plugs enough yet to know if they're having the same issues. It may be the wifi in the hub just isn't very good. While nothing else in the room has had any issues with my wifi, the hub is reporting fairly low signal strength. I still want to experiment with switching to devices over to using a local MQTT server and see if that helps. It seems like all the other HA systems (HomeAssistant, OpenHAB, etc.) are doing that with these devices. I have made some progress with the plug-in, it is monitoring the state of the plugs and the door/window sensor.

I finally got the devices that I ordered. I didn't realize they were going to be shipped directly from China. I got a pair of smart plugs MSS115 and a door/window sensor + hub. So far, I'm very not impressed with these devices. I've managed to get the door/window sensor and hub added to the app, but no matter what I try, I can't get the smart plugs to add. They always fail to add. To get as far as I have, I've had to turn off my 5G wireless network and some of the steps in their troubleshooting info seems crazy. I have been working a bit on a plug-in, but that's having about as much success as getting the devices added. Although I have learned that there are multiple ways to communicate with the devices. 1) Using the Meross MQTT servers. With this, commands are sent to the server, and status responses are returned via the server. This does seem to require that the devices be added to the Meross app. 2) Create a local MQTT server (Polisy/eisy can do this) and point the devices at it instead of the Meross servers. I suspect that once you do this, you lose access to the devices via the app. I believe this is what the integration for HomeAssistant does. 3) Use direct http commands and polling to the devices locally. I've seen some references to doing this, but haven't found any good docs/info on how. I think this is the direction I want to go with the plug-in since it doesn't require any specific configuration of the devices and doesn't seem like it would interfere with any other app controlling the devices.

The plug-in provides a mapping of ID to the string value to IoX. The Admin Console, UD Mobile and IoX make use of that mapping. I believe it is IoX that would need to use the mapping to do the ID to string substitution in the notification. In most cases, they seem to read the available mappings only on startup. If IoX hasn't been restarted since the plug-in was installed, it probably doesn't have the mapping in memory so it can't do the substitution. Restarting IoX may resolve the issue.

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