bpwwer

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.

I spent many a summer vacation in northern Michigan. Before they retired, my grandparents owned an ice cream/snack shop and motel on Glen Lake. Looks like the motel is still there https://maps.app.goo.gl/KiDMyd2BiQjJt4Es5

My first real furniture project was a 42" round table top to replace the cheap store bought table top that was not looking so great. The panel was a glue-up of red oak boards and I used a router with a circle jig to cut it out and finish the edge. I did this when I had a 2nd floor condo unit that was about 1000sf. Of course I did this when I was single and the spare bedroom was my workspace. I still have that table today.

My shop is small, 1/3 of a 3 car garage so walking over to the dust collector isn't a big chore, but I did use it more when the remote control worked. I can't recall ever being zapped by the dust collector ductwork, but then I don't typically touch it either. The one end that can be moved to different machines is plastic so that probably helps.

It really sounded legit until I got to that part. Being a woodworking myself, I can't imagine any reason to automate a table saw. Now I have tried various X10/Insteon on/off modules with the dust collector. Most don't last long though.

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