bpwwer

I think #1 would be a UDM issue. I've always considered the AC to the standard, if it works there, it should work everywhere. But with the new eisy-ui, that may have to change. If the level stays set in the AC, that implies that the plug-in isn't changing it. For the light turning off when setting the level, it's certainly possible that the plug-in isn't sending the correct messages, but since I don't have any documentation that would describe what messages to send, I'm relying on other projects that have spent time trying to reverse engineer the protocol and that could have incomplete information. I believe this happens on a dimmer switch device as I don't believe I've seen that issue with the dimmable bulb. I'll look at it again, but if I remember correctly, the plug-in sends a set-level message followed by a set on message. Maybe if I can combine the two messages into one it will resolve the issue, I'll try that, but I don't have any switches (dimmable or not) to test with. I do need to look into why it stops working. As I said, I'm seeing this every day or two, but it could be related to the number of messages being sent so I'll try repeatedly sending messages and see if that triggers it sooner.

I think that UDI broke a bunch of plug-ins with an update. Errors that start with "error: NS:" are coming from the interface library that the plug-in uses to interface with PG3x. That library is maintained by UDI but I'm not sure they actually test to make sure it works when they release updates. The deployment directory is "000db95608c0_10" so you'd have to do an "ls -la 000db95608c0_10" what files/directories where created when it was installed.

I believe that the proper behavior of setting a dimmer to on, is to set it on to the level specified by the level, so I'm not sure it's wrong, but it also may depend on the type of dimmer, seems dimmer switches and dimable bulbs behave a bit different. I believe the plug-in queries the device for current state and the level should be part of that. I think I mentioned before that the plug-in is not turning the light off when you change the level, that seems to be the device itself. However, it is possible that the plug-in is not sending the correct commands. I've been having a problem where the primary device that I'm using (I have one bulb as part of a scene that turns on at sunset and off at 11:15pm) seems to stop responding and the plugin gets stuck waiting for a response. This is happening every day or two and I have to restart the plug-in to get it working. When reporting something that seems wrong, please let me know what type of device.

The missing modules are used for creating the Roomba room mapping, which the plugin doesn't use. Thus the missing modules are expected and not an issue. I don't know why it gets stuck trying to initialize, I don't have that problem with my Roomba, so not something I can easily debug. I did add some additional debug info a couple of versions back, but so far, none of the logs you've posted have had that specific debug log message. Please set the plug-in log level to debug, restart the plug-in, note the time and once it gets stuck, download the plug-in log file and PM it to me. That way I have the entire log.

All values passed to IoX by the plug-ins are numeric. The plug-in supplies a file that maps those numeric values to a text string and IoX is supposed to use that file to provide a formatted output with the numbers replaced by the corresponding text. What you're seeing is an IoX issue, not a plugin issue. Restarting IoX so that it re-reads the mapping file may resolve the issue. If not, submit a ticket to UDI.

Local. The plug-in connects to the smart hub and all communication is between the plug-in and hub.

Fixed the name error in 2.0.14 @Lore I don't see any errors in the log but I also don't see that it ever called the initialization function so I don't really understand what's happening.

Looks like I forgot to push the changes from my local copy. I just did that so it should update to 2.0.13 now. Set the log level to debug and then download the log an either attach or PM it to me.

The problems looks like it's happening in the UDI node.js interface library. I'm guessing they never tested it with the upgrade to verify that it works. I'm no longer maintaining that library so you'll probably have to contact UDI.

version 2.0.13 has the additional info in the log message

That's where the log stops? After "Create Roomba Object" it calls into the external roomba library and tries to initialize the robot. One of the very first things it does it output a log message, which isn't in your log. Can you check the PG3x log to see if there are any errors there? The only thing I can think of is that it's calling in with bad parameters. I'll add a log message to log what parameters it's sending.

Sorry, my mistake, fixed and submitted as version 2.0.12

What I see in the log is that the Emporia server is returning 500 - internal server error for all the requests between 12:15am and 7:25am. During that time nothing will get updated since the server isn't responding with anything but the error. After that, the server starts responding with data and continues to do so through the end of log. It doesn't look like the plug-in was restarted at 7:25. A 500 error is a pretty generic error. It simply means that the server encountered an error while trying to handle the request. Since the server is able to handle the requests from the plug-in normally, this tends to rule out the plug-in sending an invalid request. It's possible that the Emporia server is overloaded and doesn't have the resources to handle the request, but I believe there are other errors it could return to indicate that. Most likely is that the server handling the request simply can't connect or access the data from their internal database, which generates an error and that's passed back to the plug-in. Most of the errors showing up the log are coming from the libraries used by the plug-in to make the request. The plug-in is throwing one error too, and I could trap that, but it won't be able to handle all the other errors that get logged when the server doesn't respond properly. From this log, I don't see anything that would indicate that the plug-in would be causing any resource issues with PG3x or IoX. In fact, when these errors are occurring, it's putting less load on PG3x and IoX because it's not sending any status updates to them.

WeatherBit is a bit of a pain right now. More than one person (including me) have had issues where our API key is fine, we're not exceeding the rate limit but it will still return API key not valid to queries. There's nothing I can do from the plug-in side to fix that, it's all on WeatherBit's side and they haven't been responsive to support requests about this. My best guess is that they really don't want to support the 'free' plan anymore, but who knows.

PG3x has a log file that you can access from the main PG3x menu (just called 'Log'). This log will show any errors when starting a plug-in that occur before the plug-in actually starts.

Submitted version 2.0.11 to the store. This has an updated getPassword() function that should be compatible with the latest OpenSSL versions.

Yeah, all my fault. Made what I thought was a simple change and didn't test it. Fixed in 2.0.10 which I just submitted to the store.

Ok, with multiple people seeing the same thing, it probably means that I screwed something up. I'll take a look and report back.

The plug-in log viewer can't show historical log entries. When you click on the log tab, it connect to the log file and then will start showing new entries as they are output to the log. If nothing is showing up, it could be because no new entries are being logged. In some cases, when the log tab isn't working, I've had to refresh/reload the log tab to get it working again.

Very rarely, or if PG3x crashes it can fail to kill running plug-ins. From your description it sounds like that's what has happened here. There is a copy of the Roomba plug-in running but PG3x thinks it has stopped that copy. Only one copy of a plug-in for a slot can be running so when you try to start a second copy, it can't and nothing happens (other than the message that it is already running). Depending on your comfort level with FreeBSD command line, you can either ssh in and kill the running copy or simply reboot the eisy/Polisy. Once that first copy is stopped/killed, you should be able to start it again from PG3x.

I don't know then, if it used to work, nothing has changed on the MH plug-in. Maybe try viewing what's happening when you press the keypad button using the diagnostics -> event view on admin console. That should show the incoming message from the keypad button and what the IOX sends out in response. If your system is busy doing a lot of stuff, it may be hard to pick those out of the view as it will also be showing all the other on-going activity.

bla I think it has something to do with the way IOX creates and handles scenes. An Insteon only scene programs the responders to respond to an Insteon broadcast message sent by the controller. In a mixed scene (Insteon + plug-in based device). That won't work because the plug-in based device (MH) doesn't use the Insteon protocol and can't respond to the broadcast message. IOX should know that the scene is a mixed device scene, but I don't think you can program a keypadlinc button to send anything but broadcast message. The keypadlinc will only send direct on/off commands for the main buttons. So that probably explains the behavior. When IOX tries to control the scene, it sends the proper command (may a broadcast) to control the Insteon devices and sends an ON command to control the MH device. So it all works as expected. But the keypadlinc only sends to broadcast command which controls the Insteon device but not MH device. The only workaround I can think of would be to supplement the scene with a program. If keypadlink button X is on, send on to MH device. This would probably be something you should submit to UDI as a ticket. They can then investigate if there's some way for IOX to handle this internally.

I'm seeing failures every few days where it seems like the device just stops responding. I'm connecting to the MQTT broker on the device itself, not remotely via the server. I haven't been able to investigate it yet, but it may just be badly designed hardware (well, probably the device firmware)

It appears that you don't have the updated roomba.py file. The failure is showing on line 42, which in the latest version is a blank line so very likely not a failure. The current version of roomba.py is 2.0.2, version 2.0.0i would have that failure on line 42

Never mind, that took about a minute to do so I just submitted version 2.0.9 to the store