bpwwer

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.