bpwwer

I found the problem with the outlets so that will be fixed. The plug-in is becoming unresponsive when it is waiting for a response from the Meross server and it doesn't get one. It is supposed to time out after 15 seconds (maybe that's too long?) but that doesn't seem to be working. I'm not really sure what to do about that yet. The behavior you're seeing with brightness level vs. on/off is how the plug-in is currently designed. The brightness level control and on/off control in the Meross API are separate controls. So right now, setting the brightness is supposed to do only that. If the device is off, changing the level doesn't turn it on. I'm guessing from your description that the App behaves differently and setting the brightness level does turn the device on (if it's currently off). I can change the plug-in to do this which probably make more sense. I don't have any devices that have brightness so I can't really test it. But I did order a couple of the RGB bulbs so at some point I will be able to test. I'm adding a custom parameter to force the use of the remote communication method. Setting this will bypass the auto-detection code and should speed up the initialization a little more. But it's still going to take time.

@dbwarner5 I just pushed version 1.0.5 to the beta store. I made some pretty significant changes in this version to try and get everything working and to make it easier to fix any issues that are still present. After install/re-installing this version, remember to check the log level setting, it should be 'debug' by default now, but if not, please set it to that before doing any testing.

It looks like the plug-in lost it's connection to PG3 at that time. The log doesn't show why. There are a couple of errors right before that but I don't think they're related. That's why it paused there, it was attempting to re-connect, which it did. The query looks like it worked, it simply sent the current values for the bulb to the AC and that looked successful. The ON command made it to the plug-in and the plug-in supposedly sent the command on to the Meross server. I don't have any logging happening to verify that. But somewhere in there, it appears to have hung. There's no response and and even though it should timeout and continue, it that never happened. From this point on, I see in the log that you sent commands, but none of them get handled by the plug-in at all because the plug-in appears to be stuck processing the ON command above. So there's nothing more you can do at this point. I get another release published soon. The details you provided are really helpful so thanks for that.

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.