Version 0.1.3 Released
HE is supposed to be not setting the same value in processing the event which is subtly different. I was getting several hundred events in a few minutes at the start of a print which occasionally triggered Hubitats excessive events warning. People would complain about that even though it's kind of benign. I changed the number of events generated.
If you stay subscribed, then that's to be expected. You're going to get a flood of event changes for the bed/nozzle/chamber coming up to temp at the beginning of a print cycle. And I'm talking like getting an attribute change event every second. That's why I implemented the subscribe/unsubscribe method to help alleviate those pains.
I don't believe your proposed changes are going to make any difference here since the duplicate values are already being suppressed. The proposed changes would have the driver doing more work to achieve the same end result.
Yes, as I pointed out early, I do NOT unsubscribe. I understand that your solution for too many events is different from my solution. I don't miss events so there is some merit to processing all of them.
What do your device stats look like?
Updated from HPM recently. Nice little addition to my tablet dashboard interface, as well as one on my phone dashboard. Ended up setting the update schedule to 120 as I didn't want it to be too chaotic in updates, especially if it is just sitting idle. Might look into adding a smart plug back in to remotely power it down when not in use, but for now the idle seems pretty reasonable even when powered on. Updated stats at 120.
One suggestion I have would be to have two update intervals. One when printing, and one when idle. That way I could set a 5 minute idle time, and a 1 minute printing time. Probably not necessary though, every 2 minutes for updates seems pretty good for me honestly. Definitely more information than I had before!
Going to also integrate into Webcore to turn off the lights when it is done printing. Even if it only saves 1W worth of draw, it is something for energy savings.
I have a virtual switch 'Bambu Printer' that Alexa can use and a Luton Pico next to the printer will also trigger the virtual switch. Then a rule to turn off the outlet the printer is connected to.
You can do this with Rule Machine, and probably webcore. It's why I made the interval a command. You just setup the logic to trigger when printing starts (maybe something like progress showing 1%) and then use the command to change the update interval to XX seconds until progress hits 100%.
Ahh yes good point, I didn't think of that. Yeah I have a monitor on percentage, so once that jumps from 100%, I can just trigger it to set a lower refresh rate and back once it completes
I am perusing a more accurate way to detect that a print is in progress. I grabbed some data last night and just need to skim through it.
Version 0.1.4 Released
Added a "currentPrintingStatus" attribute.
The ones I've found so far are:
FAILED
FINISH
IDLE
PREPARE
RUNNING
PAUSE
Should come in handy for automations:
I'm guessing that this was with powering down the printer when not in use? I tried your proposed code and, as expected, after 9 hours the utilization was a little more than my code with a 5 second interval.
The uptime was 2 days and some hours. During that time the printer was only active for 4 hours - my guess. Like all usage statistics those won't tell you everything you want to know. Then again the printer only sends every 1.0xx seconds so an estimate of how long the printer was 'up' could be made. I don't find a compelling situation or a surprise in either set
I more mean as a comparison between what I originally wrote and your proposed change. There was next to no difference in resource utilization and doesn't have any impact on the events. So, I'm going to close the issue. I've seen as many as 17 messages in a second during printing.
There's been a recent commit to Klipper to split out the MQTT updates into multiple subscriptions so you aren't getting everything all the time. There's an issue open for Bambu (since the printer firmware is based on Klipper) to have them add the same functionality. If/when that's implemented, I'll change the code accordingly to minimize the data Hubitat is crunching.
That change would be more like what octoprint exposes to mqtt - nozzle temps on a completely different topic for example. Of course if you want to display that, you need to subscribe so It probably wont help you. I'm not trying to talk you into making my changes. I have a driver that mostly works for me. Feel free to delete the message at github if you like. I haven't looked at the latest you've done with events for 0.1.4 but that was the kind of stuff I was looking for additional notifications.
I was using the the logTrace in the parse() method and never saw anything that frequent but I didn't spent a lot of time looking, but it was printing.
I send all my log data to splunk so it's pretty simple to get stats on message count and whatnot.
I'm not sure what you mean. I only toggle the subscription to help minimize load. If the sensor data is split out, I can easily adopt to subscribing to the relevant topics as needed (while leaving an option for others to stay permanently subscribed).
I was talking about the proposed changes to Bambu/Klipper/Mqtt and the use of more and narrower mqtt topic. If you want to track it on Hubitat, you need to subscribe to that topic so in the end, the proposed change at Bambu might not matter much to the HE message frequency.
Right but there's an entire barrage of messages separate from the sensor statuses that also come through on the only exposed topic right now. I'm talking XYZ coordinates of the toolhead and other superfluous (for an HE driver) data that could then not be subscribed too. Depending on how they split the topics up, it would go a very long way to reduce traffic.
Of course, this all depends on how they implement it.
EDIT: Just read through the Klipper change and the option will give every attribute it's own MQTT topic. I think the hurdle for Bambu is that they'll likely need to update Handy and BambuStudio to support the change
Download the Hubitat app
