Yeah, I just figured it’s worth nothing it goes wonky at times and to exclude (something, maybe 0°C or lower) from being logged to avoid mess in the data.
The hall sensors are used for the filament jam alerts you get when it breaks in the PTFE from what I recall, so like, when it breaks between the feeder onwards. I’ve not had need to take anything apart on mine so don’t know exactly where they are located or reading → what is going on mapping.
Humidity depends on temperature anyway, so if they are using the temp sensor to properly compensate that’s good.
@WolfwithSword have you noticed HA log issues over time using your new flow? I’m seeing the HA log get flooded with MQTT status messages and wondering if there’s a way to mediate that. Makes reading the log for anything else almost impossible.
Never noticed it, but I rarely look at my HA log and usually have my printer off when not in use, so the MQTT message relay isn’t as constant.
I think you may be able to put in a filter RBE to only pass on messages when there’s a change from previous value (distinguish by msg.topic), but @mkosmo found that it was not very consistent or caused some issues. It might work with some tweaks though - I only have used this filter node once and it was a hassle for it to work even when the value changed, had to force it to work if change on a numeric value was >= 0.001 otherwise even if it was multiples greater, it didn’t think it was a change without that specified amount for the deadband.
Another change from my personal flow and this one, I removed the expire_after setting in both config nodes, and rely on the printer’s offline status for marking unavailable. This was because for long prints, some values that don’t change would end up going unavailable.
Edit:
I should have tested my suggestion, I think it actually works. I’ll update my gist later with this filter node.
I ended up removing it for now. I had restarted HA earlier and now with the filter in place, a bunch of values are wrong, unknown or empty until I removed the filter node. It might fix if I added a dummy-load when it switched to offline status to change them before going unavailable, but now that I think about it, that also won’t survive a restart of home-assistant maybe…
Not sure if I’ll look into this later but be warned if you restart HA and use that filter node, some data won’t be present until the values actually change (change filaments in ams, new print, etc for each possible value), or you remove the filter. Not going to update the gist, just adding a comment for it.
Edit: Looks like you may be able to pass a “reset” to the filter, looking at its documentation. I think if you can reset it on HA startup it should be fine. How one does that I’m not sure, I’m probably going to poll its status using the HA integration/api - I can’t test the HA mqtt connection as my mqtt is not part of my HA technically.
Could also set it to send a reset on an injected interval, force an update every X minutes for example. Multiple ways to approach it.
My issue was during R&D/testing, I needed it to update and it wouldn’t, so I bypassed the RBE nodes. Even now, I’m not using them because the flow (x2, for two printers) isn’t creating any meaningful load on my HA/Mosquitto instances.
I like that idea. I had no idea the filter node could be reset by payload.
Supposedly if you send msg.reset (with any value not false or 0) with no msg.topic, it will reset all values. However I assumed if I did it, and put a debug after, I will get a flood of new messages as all should be passing through, but I did not. So I’m not sure if it even works
Edit: And even with the “reset” in the filter, now when my printer is off, it randomly decides in mqtt to pretend it’s on again… Yeah I think I’ll just remove the filter personally.
I got the device setup in HA as an Integration, however having a few odd issues at the moment, as I think my actual HA component code is a bit buggy. Documentation for component developers isn’t fantastic, so trying to route my way around to get to the bottom of the issue
Create a folder called bambulabs in your custom_compontents directory, and then clone the repo contents into it (git clone {URL} .) and you should be good to go. Obviously, this is in no way a working Integration.
The included python library in pybambu folder logs out the MQTT updates as they come in, but for some reason I’m having an issue passing this back to HA
To Do:
Update pybambu to pass back the device serial number in the models. Then feed this in as the unique ID
Populate models in HA Device
Fix getting information for initial setup in HA and updating data
Using it with the filter my HA would not Autodiscover from MQTT, and I saw no /config message topic when looking with MQTT Explorer. This probably should be sent every so often to be sure?
Had issues with this filter node in other flows, withouth is is a flood but a working flood…
Yeah, the filter node is not really working, but without it there’s a flood of messages as you said. I’d recommend removing it. In a few day I may update the flow and just have it disabled but still there and bypassed so most people can do it at their own risk. Additionally I’m adding a few small changes to the timezone/start/end time stuff as it randomly just broke for me again and finally found a solution that should keep working
There must be some way to get the filter node working properly though, need to look into what other people do to filter mqtt publishing in NR flows to reduce messages. Otherwise this seems like a glaring issue, as even with me injecting a reset to it, it still doesn’t work.
It was pretty dumb - I had it set to ignore initial values thinking that “oh, it must mean it will always allow initial values to pass through”. Turns out that is not how it behaves. Now I have it set to always block unless changed value per topic. Additionally, the msg.reset had to be a boolean true - so much for documentation saying it just had to be present with any value.
To get around the issue of the auto discovery not working and it being weird on HA reboot, I have the following methods/proposal:
There's an inject node in the new updated flow (Rev 9+) that will reset the filter every 5 minutes (This can be configured to your liking)
Additionally, I setup a button that lets you manually reset the filter whenever you want.
For HA startup, since the button won’t be available, you can instead publish to the button’s topic using MQTT publish in an automation. I have an automation in HA for bootup anyways so I added it there.
This way, anytime HA is restarted (machine, brute force or via dev tools etc) it will reset the filter in NR and let all the printer details get published - only takes as long as the automation!
For first time setup in HA, the MQTT auto discovery may not pick them up until the inject interval happens or you publish the reset_filter topic, but it should do it eventually now. Feel free to adjust the timer to whatever works for you - I felt 5 minutes was a good balance of “make sure it’s reset” and “don’t clutter my logs” for me.
I have your latest flow installed @WolfwithSword; so far so good. Your filter is working better than my attempt. I’ll keep an eye on it after restarting my printer/etc.
Yeah, I stopped right around this stage in my attempt. Issues with the config flow properly connecting to MQTT (and setting up framework for starting its loop for auto reconnect attempts, FTP etc), then actually connecting it as sensors was lackluster in documentation. Even swapped to butchering another hacs repo that I use (Anycubic Mono X integration) for sensors and it still didn’t work out.
The new NR flow satisfies all my needs so I’m not pursuing a integration anymore but if I get the time I’ll take a look to see what I can add to that, based on the data made available in my flow.
Quick thing to consider: The P1P and X1C are not the same with mqtt messages, so it will be easier starting early to set it up to differentiate the codebase for adding one or the other, even if you don’t have the P1P part setup. That way it’s easier for someone to add it later.
thats correct p1p isnt the same as the X1, The p1p only reports state changes to Device/serial/report.
maybe that @darkorb could explain how he got his data from the X1 so i can try to give it a shot on the P1P
@WolfwithSword told me on discord about mqttexplorer and i’ve tried to connect to it but keeps disconnecting and not displaying data unlike the X1
The p1p only reports Nozzle temperature, Bed temperature, thats about it. but i know it tells the bambulab app everything else, i am not sure if thats using mqtt though
