bpwwer

I see the issue with the bulbs, they should still be responding to changes made in the app and to the controls on the AC. But the error is what's causing them to so the brightness level instead of off when they are initialized. You probably need to remove the duplicate nodes from the AC (right click / delete) and the plug-in will recreate any if necessary when it's restarted. Looking over the log, it looks like the plug-in is doing what you ask it to. However I turned off a bunch of the debugging log messages accidentally so the log isn't showing what the Meross server is sending so I can't see everything that's happening. I'm going go through things a bit more and I'll release a new version with the debugging enabled. Or if you have a chance, you can enable debugging log from the PG3 detail page log setting. Just set the level to debug and then run through some of the same steps you did above and send me that log.

The automatically updates on your machine, every 8 hours. You can force an update with the "Refresh Store" button.

@dbwarner5 I just published version 1.0.4. This should take care of a lot of the issues.

I don't know and I have no way to investigate that. From the information about the WeatherBit API, the number of queries made by the plug-in are the only thing that should trigger that and the polling setting is the only configuration of the plug-in that controls the number of queries it makes.

The error is coming from WeatherBit https://help.weatherbit.io/faq/what-happens-when-i-exceed-a-rate-limit/

I believe the 429 error is because you've exceeded the number of calls you're allowed to make (in a day, if I recall correctly). You may need to increase the polling interval.

Actually, I decided to test setting the name to a longer value and it seems that they did increase the limit at some point. Looks like it's now 28 characters. I've updated the plug-in so you shouldn't have to change any names at this point.

The name limitations are in the eisy but I don't think it really cares what the names are. It mostly uses the node address to interact with nodes and the name is just there for you. The plug-in will make sure the names it assigns to the node are valid (well it should now). To make the longer ones unique, maybe switch around the parts. So instead of Family Room Main, use Main Family Room. That may be hard to remember though for trying to control via Alexa. Before you make changes that screw up your setup, let me send off a note to UDI to see if updating the eisy node name restrictions is something they'd be willing to do.

The only ones I see failing in the log are the outlets, but I can't tell why they are failing. For everything else, the plug-in is sending the commands to eisy to create the nodes and it's not getting any failures back. I do see something that might cause some issues. eisy has a limit of 14 characters for node names. Looking at the outlets I see a device "Outside Front " and another "Outside Front Main" When "Outside Front Main" gets truncated to 14 characters, it's now the same as "Outside Front ". I don't think the eisy cares that they're the same, but it could be a bit confusing for you. Also, since these outlets have multiple plugs, the plugin will suffix each plug with an "_1" and "_2" to try and create unique names, further limiting the names to 12 characters.

You can wait and do that with the next release. I'll try to get something ready in the next day or two.

I don't have the plug-in configured to rename the nodes so it simply didn't rename any of the nodes that already existed. I'll change that so that it does rename them to whatever is set in the app. Looking at the "Chairs" dimmer that says it's at 20% I see it sending: {'togglex': [{'channel': 0, 'onoff': 0, 'lmTime': 1745019070}], 'triggerx': [], 'timerx': [], 'light': {'capacity': 4, 'channel': 0, 'luminance': 20}} It's sending a luminance value of 20 so what the plug-in is reporting is what the device is sending. However, the device is also sending onoff as 0 (off). The plug-in currently is assuming that the luminance value is what represents the current state of the device, but that appears to be not true. This may also explain why you can't control them. If the plug-in is only changing the luminance and not the onoff state, you won't see any change in the device. I'm not seeing any place in the log where it tried to send a command to a device.

Wow, I really screwed up with that version. I think I fixed the bugs now and just published version 1.0.3. You should be able to just re-install this version but you may have to delete the nodes from the admin console so it can re-create them with the correct names. I'm not sure if PG3 will update the names.

Ok, I added a new purchase option so this will give you a permanent license for the betas and the final production release.

Sorry about that. I'm trying to use the trial licenses for limited time beta releases. The second release was supposed to have 30 days but it sounds like it's still trying to use the license from the first release. Try deleting your current version and see if it lets you "purchase" the new trial. If that works, great. If not let me know and I'll add a perpetual license.

Published version 1.0.2. I think I fixed the bugs and discover should be a little faster now.

That's good data, thanks! I see a couple of bugs that need to be fixed. One, it's not making sure the device names are legal for the eisy nodes. There are a couple of the names that are too long and I see at least one with a character that's not supported in node names. That's a pretty easy fix. It also looks like there's a bug in the switch nodes. I thought I had tested those but something slipped through. Shouldn't be a big deal to fix. A lot of the errors are just the plug-in trying to connect locally to the device and failing. I thought I had the logic right to make one attempt to connect locally and then mark the device as a remote device and not attempt local connections anymore, but that doesn't seem to be working given how much it's attempting local connections. This is probably the biggest issue. I've designed the plug-in so that it tries to mimic how the eisy handles Insteon and Z-Wave devices. Thus, there isn't a "controller" node, just device nodes. There's both pros and cons to doing it this way with the biggest con being that it does make it more difficult to find the nodes for testing. The eisy only allows for a single parent/child relationship between nodes. I'm currently using that for devices like the indoor/outdoor 2 outlet device and hub/sensor devices. If I grouped them under a controller, I'd no longer be able to have the multi-outlet or hub/sensor groupings. Trade-offs. I think a lot of the time it's taking to discover is because of the check to see if the device is local. It looks like that takes about 30 seconds.

@dbwarner5 It took a bit longer than I expected but a new beta release, version 1.0.1 is now in the store. I added support for all of your devices and have tested them as best I can without having the actual devices. The indoor/outdoor outlet should show up as 3 nodes, one main node and two child nodes, one for each outlet. I think the main node will control both outlets (I.E. if you turn the main node ON, both outlets will turn on), but I'm not sure. The switches should have both status and control. This means you should be able to use them as scene controllers and also in programs as a control trigger. A control trigger should allow you to create programs based on pressing the switch on or off, vs. the status of load. If the switch has been turned on such that the light(load) attached is on, it's status is ON. If you press the switch on again, it's status doesn't change, but it should trigger the control switched on. So while you're testing thing, keep track of any issues and then send me the log (the log resets each day at midnight so don't wait), along with the device(s) and issues(s).

Yes, you should be able to do that, assuming the plug-in doesn't have a bug that's preventing it from working. Since you mentioned Ambient and solar radiation, I tested that and it seems to work as I'd expect. I'm not sure if this actually works, but the ideas was to set the variable to the solar radiation value, wait 1 minute and then add the new solar radiation value, then divide by 2 to get the average solar radiation over that 1 minute interval.

@dbwarner5 I just published a test version to the non-production store. You'll need to enter your Meross user/password info in the configuration and once you do that it should enumerate your devices (in the log). Since I don't think we have device type overlap, it won't create any nodes or really do anything other than log what devices you have with their info. Send me the log (via PM is fine) and I'll start working on supporting your devices.

The idea was to use a local connection when possible and for my initial development I've been using it to send commands to the devices. But commands can be sent direct to the device IP address or to the Meross server, I just haven't written that part (yet). Right now, the only commands being sent are on/off for the plugs, periodic queries for device on-line status, and a query for the device WiFi signal strength. What I have now will query the Meross servers for the devices associated with your account. For each device, it will query the Meross servers for some additional info on the device and then try to create a node for the device. It sounds like we don't have any overlap in the devices we have so when you run it, all it will end up doing is documenting the details about each device in the plug-in's log file. I can then take that log info and add support those devices. Given the devices are remote to your currently location, I just need to figure out a way you can choose, how you want the plug-in to send commands; direct or via the server. With that, you'll be able to monitor/control the devices in house #2 from house#1 eisy.

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