bpwwer

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.

You can use a Caseta switch as a controller for a scene that has Insteon devices, but it's not ideal. Lutron doesn't send out control commands when a switch is used. Instead, the plug-in has to see the status change and then use that to activate the scene. What this means is that whatever load the switch is controlling and any Insteon devices in the scene are not well synchronized. I have a dimmer switch controlling a lamp and an Insteon lamplinc controlling a lamp in a scene. When the on button on the dimmer is pressed, the lamp it is controlling ramps up in brightness, then the Insteon lamplinc turns on. However, the Pico switches do send out control commands since that's what they're designed to do. So using a Pico as a scene controller should work as you'd expect. Using Insteon devices as scene controllers should also work as you'd expect.

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