You should just be able open mqtt explorer, stick in the IP of the P1P and hit connect 
Given itās running on a (I believe) ESP32, itās not beyond reason to expect major differences, the X1 runs Eclipse Mosquitto as it runs Linux natively on its board. The P1P they would have to implement the MQTT themselves or use one of the versions off of GitHub which arenāt as full featured as what you see with Mosquitto.
I wonder if we can duplicate and butcher the current MQTT integration. You can only have 1, but I pointed it to my X1C and listened to a topic which shows all the MQTT data coming through
There has to be a locked up topic somewhere, because it actually has all the data the X1 has but it only updates /report when something changes
Keep in mind the app doesnāt connect to the printer. The app connects to cc06b4cc-internet-facing-cc58a4f9438d216d.elb.us-west-2.amazonaws.com or similar (more accurately, mqtt.us.bambulab.com) depending on your region (which is what the printer connects to also). To get MQTT on the ESP32 itād have to be very stripped-down vs the X1.
@DutchDeveloper Can you do a port scan of the P1P? Itāll tell us what ports are open. If 1883 isnāt open, then its not MQTT its using.
Could be running using WebSockets instead, which are translated and thrown out by their public MQTT API
Just made a bit of a breakthrough
It seems Mosquitto can also act as a bridge, so now Iāve got the Bambu MQTT server streaming directly into Mosquitto.
Now we can use the Home Assistant MQTT client that already exists to pull in this data, and map it to the sensors
If you want to setup MQTT bridging, then you can follow this guide: 6: MQTT bridging - HackMD
tldr; add the following to your mosquitto.conf file:
connection bambux1c
address 192.168.1.64:1883
topic device/# in
topic device/# out
try_private false
Iām just looking through the dsmr_reader and tasmota integrations as they currently use the existing MQTT client to stream data into sensors
1 Like
Unless you have need to allow everything, filter the outbound to the printer to only ever send things related to the printer. You can cause yourself issues if you donāt.
Good point!
I think itās just something like the below, but havenāt quite figured out how this bit works
topic device/# in
topic device/# out
Top line should allow for publishing to broker only for now.bittom line, one I figure out the publish commands can be adjusted so only that topic is sent to the printer
That should work, just be careful with what you send. I know of some folks who caused themselves some pain (and a reset to defaults) with some accidental sending. Bambu will possibly not help if you cause issues from throwing MQTT commands at the printers, just keep that in mind.
I have been following ā¦ and its looking great. Here is what I pick I up upon mqtt query of the printer and your fantastic work. I just happened to switch EMQX and discovered bridging with the printer. I then happened upon your work. My info is just from a mqtt read as suggested earlier in this thread.
Have you done any analysis to determine if the mosquitto bridge is more efficient than the Node-Red subscriptions? I reckon it might be, but thatās certainly curious. Doing the translations locally for HA auto-discovery may be worthwhile.
On the other hand, that means the local MQTT broker has to do more work.
Iām not really sure how Iād even measure that to be honest. Both systems are essentially doing the same thing, although Iād argue that the MQTT Broker piece might be faster and lighter since itās built-in, and the integration then uses the existing MQTT client.
NR on the other hand is establishing a new client in its own bubble, and then feeding back to HA. Adds another hop to the process.
That being said, CPU on my server didnāt really change much when I turned the printer on either, so likely to be nothing in it.
Iād like to lose the dependency on setting up a broker to be honest. I know itās possible as I created a python library that subscribes to it directly. Ive been struggling to handle the connection of this though in Home Assistant.
Iāll continue to work on it using a Broker, and once itās done, I can carry on looking at connecting directly again
In terms of efficiency it would be complex. With the nodered flow, we now have a good filtering of messages your MQTT broker and HA donāt get bombarded with every payload, but you also need both NR and an MQTT broker setup on your machine in addition to HA. For the component, you skip on the NR layer, but still ingest in your primary broker all the messages. MQTT is quite good at this but cleanup is always nice. I do wonder about HA logs now with the component version, if they see the same problem we had before filtering in the NR flow.
Benefits of the NR setup allow additional flows to be made much easier and hooked in (I have my additional flow for the FTP Fetch of a print preview image, and some nodes setup for inserting into a postgres db print info and calculations). It also lets some nodes be more customizable (which fields are āuselessā and removed, and stuff like my known/named filament translator node for AMS filaments). Benefits of the component is itās mostly all in one - except for the bridging to another broker.
Iām a bit hesitant to bridge the brokers mostly because keeping it isolated just seems less risky and better for keeping it in its own self-dependent bubble. As @greghesp mentioned, there is a way to make it connect straight to the broker using paho-mqtt instead of bridging whichever you have setup for HA, but getting it to connect during the config flow and startup is a bit finnicky. Constantly had reconnections in my loop after first connect, and on reboot wouldnāt reconnect at all.
An ideal config flow though would be to toss in the IP and Serial of the printer (and maybe LAN password if you want to later include FTP related stuff), itāll connect to the printerās MQTT (and keep trying when itās offline), and configure the rest. Still donāt know a good way for stuff like the filament translator to be configurable unless we can have configuration YAML override global component values. And having the component add more than one device per configuration I havenāt seen examples of - Iāve really grown to like having the AMS units separate devices but linked natively.
Itād require the usual - Run them both and observe the metrics.
The broker is still required for filtering and setting up MQTT Auto-discovery, though. Unless you want to do it manually. Much of the elegance of the NR flows is in how itās natively extensible without much (if any) additional user input.
It looks like with the topic rewrites, we get the isolation bits still - but Iām still not seeing a way to get rid of NR. In this architecture, weād have to use NR to loopback MQTT and locally translate messages (which doesnāt change much other than each message requiring 3 MQTT transactions instead of 2).
1 Like
Iām actually in the process of breaking the AMS out as a separate device in HA. Theory being you might have 4 AMS devices and 1 X1C, in the component youād see 5 devices, all with their own sensors
For auto-discovery, yes, but itās possible to use the paho.mqtt library to connect directly to the printer, and have HA manage the connection. This is exactly what the MQTT component does, weād just need to simply and replicate it.
This way, you can pop in the IP address of the printer, and pull the rest from the direct MQTT connection
Interesting you say this. My MQTT Bridging has stopped working. Nothing changed in the configuration, and I can still connect the MQTT Broker on the X1C 
Just quick reply and no answers here but, I noticed your code stoped working while playing around. I had to roll back to around to your release around 5pm EST USA to get working again. It was before you started and rolled back the AMS.
The only remaining challenge is the business logic, then. If BL was splitting topics per metric this would be easy, but the monolithic message with JSON-for-all would need to be parsed.