Yep, there are a few variables I think mentioned in a comment. All get replaced using a script from the configurator if you want to see what type of ones to look for. Don’t think the yaml has too many.
Just to follow up on this, it seems like it’s Bambu Studio (and perhaps Bambu Handy) that trigger messages to start flowing. I’ve noticed that @greghesp 's integration will stop getting updates after a while, but as soon as I open Bambu Studio, his integration will get a flood of them.
Yeah that’s what I mean - bambu studio and/or handy reconnect to it so it triggers it again. P1P’s implementation of mqtt isn’t full, so I’m not surprised if it does this. Almost like a timeout until something reconnects to “wake it up”. Actually since it’s esp based, probably exactly that - it’s put into a sleep mode until something new connects to conserve power/resources.
Likely using the cloud approach would work since that connection never drops, and the printer just pushes to the cloud on update.
Only other way I could think of a “workaround” is to force a disconnect and reconnect in an interval to the mqtt (~30m or so? it would potentially mess up stuff in the NR flow if it were mid print) which is not really ideal in either the NR flow or the HA integration, but could probably be done in both.
I originally thought that it was the connection from Node-RED or Greg’s integration that triggered the flow of data (when I was playing with MQTT Explorer), but now it’s looking more like may have opened Bambu Studio or the app to cause that.
I’ll have to play around some more but if it wasn’t the connection from Node-RED or Greg’s integration that caused the messages to start flowing then I don’t think reconnecting on an interval will help. We’d have to figure out what Bambu is sending to the printer to get it going.
Next time I notice the data in the integration going stale, I’ll try connecting from Node-RED or reloading the integration etc to see if that gets it going again. I suspect it won’t 
Oh I should also mention that the reason I personally don’t use the cloud approach is that I noticed the updates were quite delayed.
I’ve seen others with this P1P issue and for them just anything disconnected then reconnecting from scratch fixed it. Such as in nodered, re-deploying the flow. Hence the suggestion.
The app/studio would be the same thing - “new” connection triggers others to be active again / new connection is fresh as is.
Could probably setup some custom nodes for just your flow that will disconnect and reconnect the mqtt in your nodered flow alone on an interval. If some of your testing shows it could work I can send you a small mockup flow for it with instructions on setting it up.
What makes me think it’s not as simple as just anything connecting triggers the data to stay flowing is that MQTT Explorer didn’t get data flowing at all, something else triggered it. You mentioned there could be a difference in how MQTT Explorer handshakes vs Node-RED and the python client, though. Maybe there are two layers to it. Either way I’ll try to do some testing and report back with my findings 
The HACS integration is setup to automatically reconnect to the printer if the MQTT connection drops. And on reconnection it asks for all the latest state and there’s no known issues receiving that either. So, modulo bugs, to get the behavior you describe the printer must be going into a sleep mode that stops sending data but doesn’t close the mqtt connection. I’d be more inclined to believe the printer has a problem and is getting into a hung state that a fresh connection attempt from another sources breaks it out of.
I get constant data from my P1P - almost every second although there is occasional gaps because the reported wifi power level changes very slightly typically about once a second but it’s variable so every few minutes it looks like I go without an mqtt event for over 10 seconds as that triggers HA to poll for data which I can see in the logs.
And more generally, I’m not seeing the behavior you describe with my P1P - it’s been left idle over night and I’m still getting updates from it. I am currently running in lan mode but I didn’t see any differences in cloud mode either. And no significant extra latency either - it’s just kinda slow generally to report changes - turning on/off the chamber led takes 1-5 seconds to be reported via mqtt.
OK, so no magic happens to have HA replace that on the fly - it has to be done manually or via a script during manual setup of the dashboard by the end user? I was wondering if there was a way to set that variable in the yaml in a single place and have all the other usage use that. So you can copy/paste the AMS section up to 4 times and make a single line edit to provide the serial number for all and then an additional one line edit to each to get it working for the distinct AMS device.
That’s the behaviour - it will still be “Connected” but asleep virtually. The P1P does this quite a bit to my knowledge, at least of the people who have used my flows with p1p it’s around a third who had an issue like this, granted not many p1p users.
Yep, that’s why I made the configurators for them: Bambulab Home Assistant Dashboards
It does all the work so you can just edit here and download the whole thing replaced (I separated ams, printer, etc).
Strange. I see the behavior I described with not just 1 but 2 P1Ps. Neither are in LAN mode and both have sleep disabled (but I suspect that particular sleep option only affects the LCD brightness).
For example I have an HA automation that triggers when a print finishes and I started a print before going to bed last night, but my automation never triggered until this morning when I opened Bambu Studio. I checked the device and entities in HA and noticed they were all without updates until I opened Bambu Studio. What I didn’t notice until writing this now, is that they went unavailable sometime during the print (I mistakenly thought the data was just going stale rather than the device becoming unavailable)
Oops that log isn’t for the correct printer. I didn’t even use that printer last night. I’m more than a little burnt out at the moment 
This is the correct log:
In this log it looks like the data did go stale, rather than the printer going unavailable. Speed Profile was set to Standard at 11:56:40 (when I started the print) and then got no updates until 9:29:58 when I opened the slicer.
Is it possible your printers drop network connection entirely then?
It’s possible, although I haven’t ever noticed them disconnect. They’re not far from my router/AP and I haven’t seen other devices losing connection generally either. I’ll see if I can find any evidence of connectivity problems just in case.
I just realized my findings were bogus. My main machine is set to go to sleep and I’ve recently switched to running my dev instance of HA on it. But that means when the machine wakes up, the HA instance detects the dropped connect to the printer (because the host PC was asleep) and reconnects. Which then immediately triggers a flush of the latest state.
TLDR; I’ll have to disable sleep to test this properly or turn off my test HA instance and enable debug logging on my product one (which is a raspberry Pi that doesn’t like that level of logging).
Still no repro in my fresh overnight test. My P1P was still sending it’s updates every ~second in the morning.
I haven’t touched my printers in over a day now and this is what they look like in HA:
The logbook shows some sensors being updated every minute or so on one of my P1Ps but the logbook for the other is empty. However, using MQTT Explorer, it looks like both P1Ps are pushing out regular updates (usually wifi_signal and bed_temper). Looking at the temperature sensors in HA, both are indeed getting updated frequently.
The original issue hasn’t reproduced itself. I’m now thinking that it’s not an issue at all and I might have simply not waited long enough for the printer to push out an update, and when it eventually did, I incorrectly assumed that it was a result of connecting with Node RED or Bambu Studio or something.
The current weirdness is that some sensors went stale while others didn’t. One printer still has a Current Stage of Printing, although it finished printing days ago, and the End Time sensor is still getting updates in the Logbook. The other printer has a Current Stage of Unknown and no recent Logbook entries (I only keep a few days of logs in my HA instance).
The pace that the printers send out MQTT messages seems to vary quite a bit. When I first started writing this post, one of them was sending a message every minute or so while the other was sending one every 5-10 seconds. Now they’re both sending them every 5-10 seconds. Maybe they only send messages once a sensor has changed enough to justify the update.
To circle back to WiFi concerns, I noticed that one of the machines has around -42db wifi_signal and the other -37, and they are both consistent. Those are excellent signal strengths.
Anyway to sum that up, I’m thinking that there’s no magic needed to get messages flowing, and that it might just take a long time for the printer to push one out in some cases. The other issues are likely more integration-related and for all I know I could have restarted HA and caused some messages to get missed. I’ll report back if find anything else worth mentioning. In the meantime I’m going to just keep an eye on things.
The P1P is different to the X1 - it only sends out deltas in it’s mqtt payloads. In idle steady state, that’s minor variations in wifi signal strength and less frequently bed temperature that result in updates every few seconds.
The state you describe indicates that the HA integration failed to get the delta updates for the print completing. So the ‘mc_remaining_time’ value got stuck permanently non-zero and end_time it just calculated by adding that to ‘now’. And the fact that specific one is still updating doesn’t mean that the integration is properly receiving new data even if you see it flowing - if a mishandled exception occurs it’s possible the mqtt connection got dropped and didn’t reconnect automatically. But having said that I made changes to handle all exceptions and don’t know of any cases where that doesn’t work to reconnect. Since your stuck-printing case has correct room temperature temperatures, that suggests that a set of of events got lost but subsequent mqtt updates were processed correctly.
Right as I writing this the mqtt connection to my P1P got dropped and reconnected automatically. On reconnect it requests ‘all’ data so any misssed state changes will get corrected at that point. So that suggests that the integration never detected the mqtt connection as actually dropped.
Is there anything in your HA log - that’s the next step in understanding this further. You may need to turn on debug logging (but be warned this can kill an sd card very quickly if you run your HA on a raspberry pi).
It occurs to me that this error from the underlying mqtt stream was mitigated by reconnecting the mqtt:
2023-04-16 04:45:12.681 DEBUG (Thread-2 (listen_thread)) [custom_components.bambu_lab.pybambu] Exception <method-wrapper ‘str’ of tuple object at 0x7fb5f0559de0>
2023-04-16 04:45:12.681 DEBUG (Thread-2 (listen_thread)) [custom_components.bambu_lab.pybambu] A listener loop thread exception occurred:
2023-04-16 04:45:12.681 DEBUG (Thread-2 (listen_thread)) [custom_components.bambu_lab.pybambu] Exception type: <class ‘struct.error’>
2023-04-16 04:45:12.681 DEBUG (Thread-2 (listen_thread)) [custom_components.bambu_lab.pybambu] Exception args: (‘bad char in struct format’,)
But it doesn’t re-request full data. So if the corrupt / mishandled payload had something one-time in it such as the transition from printing to not, that will be lost. That is only currently logged when at DEBUG logging level…
No past me was smarter than that, I made it re-request full data whenever the mqtt connection completed. There should never be a case that the mqtt connection dropping and reconnecting permanently loses a state change. So that leaves just a mishandling of some mqtt payload by the integration itself or a printer bug never even sending the data.
1 Like
Ah okay in that case, those are “unknown” because they were not yet received from the printer, since as @AdrianGarside said, the P1P only sends shortened messages of specific sensors that changed. If you are using my nodered approach, it should be running a command to force a message from all sensors on a timer every 5m, if some sensors are still unknown from that, then it means the pushall sensors command does not push “all” for P1P - additionally, I don’t know if “Speed profile” does ever get filled out by P1P, and current stage I doubt it would send unless it actively changed states.
And using the integration as Adrian said, it does the pushall update command too so it should be fine. Otherwise all your sensors actually look correct to me (except start time, but I have seen some P1P users not actually register “start time” at all during prints, same for layers and layer_num).
So I’d say just going by those screenshots, you don’t have any issues going on, just some sensors that are finnicky / never worked for P1P most of the time. Anytime something does change it will update just that sensor, and if it disconnects it seems like it does reconnect and update. It’s only when sensors become greyed out / “unavailable” would it be stale / not updating / not present.