bpwwer

Correct, Pico devices have no status. They only send commands (button presses). The -Favorite node is special. I tried to make that somewhat useful in groups/scenes. The screen shot shows the if clause for my Pico that is controlling 2 shades. But, if I understand what you want to do, that doesn't really help. It's saying that when the open button is pressed, do something. I believe you want to trigger the shades without physically pressing the pico's button, correct? Something like what's in the second screenshot. And as you noticed, the two command are executed sequentially by the IoX, it doesn't have the ability to simultaneously send two commands. The other option is use the Lutron app and create a scene with both shades in that scene. The plugin will create node for the scene and you can trigger the Lutron scene to activate. You'd need different scenes for different shade positions/settings, but the shades should then be in sync. IoX was originally developed to work with the Insteon protocol so for most other protocols, there are compromises. The different companies also patent parts of their protocols so other companies can't do things exactly the same way.

The short answer is, you can't. Lutron's protocols don't provide that capability. The plugin can't send commands as if they came from a specific device. Pico's simply send button press commands to the hub and then the hub sends command to the device(s) linked to that. The plugin should also see that button press and you can use that in a program to trigger other events -- if control pico-main is on then do something. The top button of the 3BRL is the on button (regardless of what engraved on the remote). You can also have a program that sends open/close commands to the shades, but you'd need something to trigger that. I believe you can also put the shades in a group and have some other device trigger commands (be the controller) for that group. But you can't send commands to the Pico and Pico's have no status. They are very simple, when the button is pressed, the button press command is sent to the hub. The hub programming determines what happens when it gets that button press event. The node would have to know the topology of the hub to know what the Pico on/open button was linked to and then have a button/command to send the on/open command directly to those devices. I don't believe the hub will share that topology info and if it can, it hasn't been reverse engineered to know how it would work. The -Favorite node is tied to the favorite button on the Pico and you can set how you want the plugin to treat that. The "Sends Command" setting is what the plugin will translate the Pico's favorite button into something that IoX can understand. Again, this would be used in programs. If set the button to "ON" then in a program you can use "if control pico-fav is on" do something.

The httpx read timeout error appears to be it trying to get connection info for slot 0. As far as I know, there is no slot 0. But UDI changes since I last worked on pg3x may be responsible for this. In any case, this is not related to your issue. The restart at 12:33:13 and what follows at 12:33:37 is strange. But again, not related to your issue. The log does show that the plugin was started last at 12:56:28 and that it started successfully. But then at 12:56:44 it logs: Is client running? /var/polyglot/pg3/ns/0021b9026000_1/logs/debug.log does not exist. So is the plugin still showing disconnected and its log file is empty? If that's the case, you'll have to submit a ticket to UDI as there's nothing in the PG3x log file that shows any issue with the plugin starting. They'll have to dig deeper into the system to figure out why the plugin isn't starting.

The plugin is running (or should be) on the eisy and the eisy's ip address in your case is 192.168.1.100 and will always be active when eisy powered up and running. From your screen shot of PG3x, the plugin is not running (status: Disconnected). The question that needs to be answered is why didn't the plugin start? You said you level the Station Name blank. What you enter here is what the node in the IoX node list will be named. By leaving it blank, the name will default to "unknown". Try this: With the log level set to debug, like what your screenshot is showing Restart (or Start) the plugin. The log file should start populating If the log doesn't start populating, that means PG3x was unable to start the plugin. The reason should show up in the PG3x log file so go click the "Log" button at the upper right of the screen. Depending on what plugins are running, this log may be capturing a lot of messages, so click the autoscroll to turn that off and then scroll back and look for error messages related to AmbientConsole. When the plugin is running, it will start a server listening on port 7501. When the plugin is not running, there's nothing listening on port 7501 so the connection is rejected.

This information is coming from eisy -> Plugins -> Configuration -> [slot range] -> slot with AmbientConsole installed right? Are you changing the port number in that "Plugin Configuration" form? If so don't. That is configuring the connection between the plugin and IoX. All current plugins do that automatically. Changing anything there will just break things. In fact, just ignore that whole menu. The only plugin configuration you do is from PG3x. From the dashboard, click the plugin's Details button. From there, click the Configuration button. From there you can configure the port # and the station name. It should default to port 7501 and the name is just a string you want it to use for the node name. All plugins also have built in logging facilities. You'll see that option from the plugin's details page. To debug issues with a plugin, you should set the log level to debug, restart the plugin and then examine the log. If you need help, posting the log here or PMing it to the plugin's author is the best way to get support.

That seems to re-enforce the idea that something is going wrong with the plug-in logging when eisy rotates the log at midnight. By increasing the poll time or reducing the log level you just reduce the chance of it happening. With 10 second polling and debug log the plug-in does generate a lot of messages so Benoit's theory doesn't contradict the above. We (me/UDI) don't recommend normally running with debug level logging unless trying to actually debug an issue. But that can end up being a bit of catch 22. Having the debug log can really help if something does go wrong but having it on all the time can also use a lot of disk space and slow things down as Benoit says.

The log doesn't show anything unusual. The plugin stops sending updates after about a minute and then after about 7 minutes it disconnects. There's nothing in the log to indicate why those two things happen. My best guess is still that something with the daily log rotation is causing the logging mechanism used by the plugin (well, all plugins really) to hang. Since the plugin can't write to it's log and nothing unusual shows up in the PG3x log, I don't really know what to try at this point. My development/debug environment is different from the production environment so I don't think I can even reproduce this in that environment. I'm not sure how UDI is doing the daily log rotation for the plugins but if they can have you turn that off for this plugin, we should know something in a couple of days. Either the plugin will not fail every few days, or if it does, the log my now have some information about why since it's not being rotated.

That's interesting. At least for the first 30 seconds, the plugin is sending data to IoX and appears to be working even though it's not writing anything to it's log. Is there a point in the PG3x log where the requests for slot 5 stop? The lines that look like this: IoX Request: [Try: 1] [00:21:b9:02:65:8a] :: - http://127.0.0.x/rest/ns/5/nodes/.....And are there any messages that would indicate why? Now I'm wondering if the daily log rotation is somehow causing the logging mechanism in the plugin to fail and after some amount of time, it finally hangs or blocks. You're polling every 10 seconds, right? It looks like in this case, that's happening at 0, 10, 20, 30, 40, 50 seconds and the daily log rotation happens at 0 seconds too. I believe the times it polls will depend on when the plugin is started so checking what times the poll is happening and see if the failure is only happening when the polling starts at 0 seconds. If there's a correlation there, this might be something UDI needs to look into.

Without any debug/errors shown for June 6, it's impossible to know what really happened. The last thing in the June 5 log shows the plugin executing a short poll event. When this event is executed, the plugin, via a third party library, makes a call to Emporia to get updated info for all devices. Unless there is some weird timing happening where the plugin tries to write to the log at the same time eisy is renaming the log file and that causes the plugin to crash. It might be interesting to see if the plugin was actually doing anything in the first few seconds of June 6 that would show up in the PG3x log or that may even have some details if the plugin crashed. Of course, since it's a new day, you'd have to do the same thing to look at the June 6 PG3x log. Those files are in /var/polygot/pg3/logs You may not need to use sudo to access these logs.

The logs are in the plug-in's directory: /var/polygot/pg3/ns/<macaddress>_<slot#>/logs You'll need to use sudo as admin doesn't have enough privilege to access the logs. Here's an example: [bpaauwe@polisy ~]$ sudo ls -lrt /var/polyglot/pg3/ns/000db94e3a44_7/logs total 16 -rw-r--r-- 1 000db94e3a44_7 polyglot 830 Feb 14 2024 debug.log.2023-09-11.gz -rw-r--r-- 1 000db94e3a44_7 polyglot 734 Feb 24 2024 debug.log.2024-02-14.gz -rw-r--r-- 1 000db94e3a44_7 polyglot 864 May 20 2024 debug.log.2024-02-24.gz -rw-r--r-- 1 000db94e3a44_7 polyglot 863 Feb 10 2025 debug.log.2024-05-19.gz -rw-r--r-- 1 000db94e3a44_7 polyglot 3591 Feb 10 2025 debug.log [bpaauwe@polisy ~]$ sudo gunzip /var/polyglot/pg3/ns/000db94e3a44_7/logs/debug.log.2024-05-19 [bpaauwe@polisy ~]$ sudo more /var/polyglot/pg3/ns/000db94e3a44_7/logs/debug.log.2024-05-19

Sorry, no. The plugin appears to be working correctly. You might want to post in the IoX Program Support forum to see if it's something with your program.

The plug-in debug log files are only active for 24 hours. At midnight, the eisy backs up the current log and then clears the active log. Likely whatever happens, happens before midnight so no data is being collected in the log from that point on. The previous daily log files are saved but the only way to access them is via the command line. Chances are the plug-in fails to re-authenticate when the current token expires or the server stops responding and plug-in needs to re-open the connection to get it working again. The latest version, 1.0.27, was supposed to try and address the server not responding issue. If authentication fails, the plug-in gives up. The assumption is that something is either wrong on their end or the credentials are wrong and retrying to authenticate won't fix either of those issues. Emporia tolerates third party software, like the plug-in, querying their servers as long as it doesn't cause issues or cause a noticeable load.

Possibly. At one time the IoX software didn't really work with fractional values. However, it does have built-in definitions for rain and rain rate so I would expect it to handle them properly. You'd have to collect the data that the plug-in is sending and what values the program is triggering at and that might provide some insight. Of course, being rain related makes it extra difficult since most of us don't get continuous rain (it may now be 5+ months before I see rain again.

For Aeris you must have an Aeris account. The configuration help lists the information from your account that you need to enable the plug-in. However, it looks like they have been bought and are now https://www.xweather.com/docs/weather-api What that means for the plug-in, I don't know. To access data from the OpenWeatherMap weather service you will need an account with openweathermap.org and a subscription to their weather service. OpenWeatherMap has been problematic in that newly generated API keys don't always work or can take 24-48 hours to become active.

Bambu does't provide any documentation on the API. Everything we know is based on people reverse engineering it. I haven't been able to find any information on what the mc_print_stage field actually provides. Google AI showed something initially that look reasonable, but since then, it's reported a bunch of different things so it's just making things up. The stg_cur field has some actual information published about it by some of the other HA products (OpenHAB, HomeAssistant). I reviewed that and it doesn't have a stage value for idle of finished. I'm not sure what to try at this point.

Here's what I found regarding printer status. The plug-in is currently using stg_cur (current stage) which has 37 different values, a lot of them are various types of PAUSE. It is supposed to have an IDLE value, but based on what you're seeing, it doesn't seem to set that. There is another reported value, mc_printer_stage, which only has 6 values so is much higher level, but it may better for the status. I'll play around with this and see how it works. Also, while googling around I came across this: "If you are unable to control the printer (e.g., sending pausing/stopping commands via MQTT), it may be due to Bambu's security features. Starting from recent firmware updates, Bambu restricts active MQTT commands unless the printer is placed into LAN Only Mode or you are running an authorized official Bambu Connect"

That may be true. I only use my printers in LAN mode anymore. I can take a look at that.

The only change I made was to the command sent for turning the chamber light on/off. Since none of my printers have a chamber, I can't test it. The run/pause/stop commands are all working for my printer. The docs I have indicate that the same commands should work for all models. But as I said, I'm running older an firmware version and given some of Bambu's recent changes, I can't guarantee that they work with the latest firmware. For the gcode state, it does not appear to be a problem in the plug-in. I see the plug-in get the proper state from the printer, I see it send the proper state to the IoX and I see the IoX respond by changing that state. Why programs aren't detecting the change in state is not something I can answer. It seems like an IoX bug to me, but it could be just the way IoX was designed to work with that type of value.

Sorry, I saw your post show up initially but the title didn't register that this was for the Bambu plug-in. I just did some testing with my A1 Mini and the plug-in is working correctly. However, the programs on the isy don't seem to register that change. You can check that the plug-in is changing the state by going into the nodes tab for plug-in in PG3x and watch the gcode state/GV10 value. The number should change as the state changes. I simply started printing a file and it switched to state 2 (RUNNING) almost immediately. I then stopped the print and it switched to state 5 (FAILED). I also checked the program status on the admin console and it is running the program on a state change (I see the last run time changing), but as you observed, the status never changes to TRUE. This may be a bug in the isy software or it may be the way it is designed to work with this type of value. Since PG3x is sending the updated values to the isy, it seems like a program should be able to detect those changes. Stop, Pause, Resume all are working with my A1 mini. After researching it, the chamber light command I send may be wrong. I can change that, but I don't think I can test it as it doesn't seem to apply to the A1 series. I haven't been able to find a command that turns on the camera light for my mini. There also could be some issues depending on the firmware version. I stopped updating the firmware on my A1's after they announced some changes that I wan't happy with.

@photogeek54 Great job! Those of us using the plug-in really appreciate you finding and fixing the issue.

The plug-in does not need the station to be shared publicly. When configured to get local data, it is getting the data the hub is broadcasting over your local network. There are only three things that can interfere with that. 1) the broadcast won't typically cross subnet boundaries (and based on your initial post, that is not a problem). 2) A firewall setting is blocking the UDP port internally (not something you'd typically set up). 3) Another program running on a machine on your network opens the address/port in exclusive mode (meaning nothing else can then open that address port). When configured for remote, you're requesting your data from the servers (and authenticating with the API key). So again, public sharing not needed. The "Station ID" and device address are two different things. With a Tempest, it's most likely a one-to-one relationship. However, with the early weather stations, a Station ID" would usually have two device addresses associated with it -- an Air device and a Sky device. The plug-in uses the Station ID to query the WeatherFlow server to get the device addresses, your preferred units, and historical rain data when it starts. If you configure a wrong/invalid station id, I don't think you'll get any nodes created, for sure you won't get any device nodes created as it won't be able to find any. When you get a replacement Tempest, it will have a different device address so you'll want to delete the node for the currently one from the eisy using the admin console. It's been too many years since I got a replacement Tempest to remember the exact steps. It may be easiest to simply copy the token, delete the plug-in, and then re-install it.

Somewhat off topic ... While I respect the right for areas to choose to either stay on DST or eliminate DST, I think it's a bad idea to stay on DST. The ISY software is actually a good example of why. To set the time, you configure the time zone and check if you switch between DST and standard time. So you (British Columbia) can't just click DST off because your time is no longer the same as what it should be for your timezone. You'll have to switch it off and then set the timezone to some other timezone that has the right standard time to match your non-standard time. It also seems like this could effect anything that's getting it's time from GPS or maybe even cell towers. Thinks like the navigation in my car seem to know what timezone I'm in and when to switch the time as it did that correctly yesterday and it's only connection is via GPS (no wireless connection and now cell connection). Changing timezone boundaries to compensate for places that stay on permanent DST seems like it would be a very difficult problem to solve since that's a global, not local change. But then, maybe all this has already been worked out and won't be a problem.

Don't think it's related to sunrise/sunset calculations. I have a lights out program that runs at 11:18pm, it didn't run last night because of the time change (as usual), but if it follows the same pattern it will run tonight fine. Maybe it is ignoring time-of-day and pre-calculating all program start times at midnight so possibly my 11:18pm program would have ran at 12:18, but probably not since that's after midnight. My lights on program did run, but I don't know when since we weren't home, but the lights were on when we got home. The best solution would be to just get rid of daylight saving time.

Welcome back! Let me know what happens.

The upgrade available notice is kinda broken. It really needs to have an easy way to see what the upgrade is going to do and a way to skip it (i.e. stop telling you everyday that it's available if you indicate you don't want it). And no, having to go to the forums and search for a post about it is not what I consider easy. When my system is stable, I'm very hesitant to install any upgrades. I'd like to know, before doing an upgrade, that there is something in the upgrade that will solve an issue I am having, if not, I want to skip it. This is for my "production" system. My development systems tend to be kept up-to-date.