bpwwer

Yes, the same way you added the first one. Install a second copy of the Caseta plug-in in an unused slot Set the IP address of the second hub in the plug-in configuration Press the black button on the hub to pair it when prompted by the plug-in

That's strange. I'm not able to reproduce any of that. After install, I get the "You need to set your API key" notice. I enter an API key (I don't have an Ambient system or account so I have to use someone else's key) The notice immediately disappears and the plug-in starts sending queries out. The plug-in does not have any code to send any other messages for PG3 to display. So I have no idea where the second box in #4 is coming from. The plug-in should be logging API key failures and if debug logging is enabled, it will show the URL it is using there. But there are no extra spaces in that URL. If you do re-install, please enable debug level logging before entering your API key and then download the log package (maybe even do a screen capture with both messages on the screen).

Well, that's one of my plug-ins and there shouldn't be anything that carries over from a plug-in restart. Next time it happens, download the log package and PM it to me.

No, it should not. "Restart IoX should only restart the IoX process. The "Reboot" button in the UD console will reboot the eisy, basically doing a shutdown -r now command. I believe the only way to power down the eisy is via the command line using the shutdown command. As far as I know, the only way to restart PG3x is to reboot the eisy**. This is not something that should be needed on a regular basis. You should be able to individually restart plug-ins using the Restart button in the plug-in's detail page of PG3. If that's not working, then it's a bug that should be reported. ** It is possible to restart the PG3x process via the FreeBSD command line, but this is not an operation that is recommended. When the eisy starts, it starts the various processes in a specific order so that they all set up to communicate with each other properly. Restarting PG3 outside of the process may cause issues.

The PG3 version shouldn't be the cause. However, the ISY994 is EOL'd and is not getting the firmware updates that Polisy/IoX eisy/IoX are getting and there have been changes in the profile file support in the new firmware that could be the cause. As you can see, we've been throwing out random suggestions on things to try but we don't really have enough information to determine what the issue is. Whenever there is a problem with a plug-in, you'll get the best support if you follow these steps when posting about the issue: Change the plug-in's log level to debug Restart the plug-in Do whatever makes the issue apparent Download the plug-in's log package PM the log package to the plug-in's author (or attach it to your post) Include the ISY/IoX firmware version and PG3 version information If you end up submitting a ticket to UDI, attaching the log package to that is also very helpful.

This type of issue tends to be related to the node definition files for the plug-in. When the plug-in starts, it sends the node definition files to the IoX. There's no retries on this so if the IoX rejects it or something else disrupts that send, the files on the IoX may be missing or incomplete. The plug-in details page has a button "Load Profile" that when pressed, will resend the files to IoX. The admin console reads those files from IoX when it starts (and only when it starts). So if the files are sent to IoX while the AC is running, it won't see the updates/new files. You need to restart the AC for it to re-read the files. Lastly, if there's been an update to the plug-in and the node definition files were changed, that could have introduced an error into the files that cause both IoX and the AC to fail while parsing them. @Geddy suggestion to restart the AC is the first step. I'd also suggest that you use the "Load Profile" button first, give it a minute and then restart the AC.

Are you saying that the RainMachine controller has failed and isn't working at all? In that case, you're right they'll probably never send you a replacement. Your only option would be to look for a used controller (ebay?) or switch to something else. Your post was a little ambiguous on that point, I wasn't sure if meant the controller had died or you couldn't get it working because they were out of business. If the controller and it's app are still working and it's just the plug-in that's not, you might want to set the log level to debug and make a post in the RainMachine sub-forum for help.

I have an older RainMachine irrigation controller. I don't use the plug-in, but the controller itself continues to work just fine. I'm not sure about remote access as that required a subscription and I've never had one. I don't know if the plug-in requires remote access or if it can communicate locally with the controller. But if it can communicate locally, that should continue to work regardless of the state of RainMachine's business.

From the log, it shows that the return response to the alert query is that no alerts are available. For a couple of the queries, it returned bad request, which implies that their servers are having issues because a few queries later it back to returning a valid response with no alerts. Doing additional manual queries, I can't find anything for VAZ505 (or any VAZ area). /alerts/active/count shows no active alerts for VAZ /alerts/active also shows no alerts for VAZ It doesn't appear that the query formats have changed.

If it's failing to start the monitor, nothing will work. The log should show a similar error with more information if the log level is set to info or debug. The most likely reason for it failing is that the port you configured is being used by something else on the system preventing the plug-in from being able to use it. The default is 7501 which is not a port commonly used but no guarantee that it's not.

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.