Yeah, I’m annoyed at how much time I wasted trying to capture the commands over the network via wire shark. I’d tried to locate the mqtt code by looking on github via the website but I couldn’t find a way to search and there’s a lot of code without a very obvious structure to guide to at least the right directory. Should’ve just cloned it and searched locally when I first thought that the mqtt code must be there somewhere.
What is the red work light? There’s also the toolhead light on the X1 - is that not controllable?
Wait - This whole time I thought the red light was the work light all because when it first came out they said “the red light indicates it’s working properly” and it would flash…
I need to test this real quick and if I somehow just completely didn’t notice the toolhead light, I will add that to the NR flow stuff as a controllable light
Edit: Turned worklight on/off/flashing and I don’t see anything going on inside my printer. I did notice that the light for the Bambu Lab logo on the toolhead was just off no matter what - do you mean this? I remember it being on during prints but I forget about during Idle…
Ah okay then. In that case yeah, still no clue what the work light is, just assumed must be red light since it’s the only light I know of that flashes. Could test during a print but I don’t have anything planned to print for a bit - too busy + still trying to finish a “recent” print, 3D Gloop for PETG is being a PITA for me, have to weld the whole thing
Any idea why my ams suddenly thinks im in alaska ? also dropped the humidity by 10%, i know for a fact i don’t have 12% humidity in there. This suddenly just happened, I didn’t change anything in nodered.
May need to restart your AMS/printer (complete disconnect from power and back) - pretty much every commercial temperature and humidity sensor can have this exact glitch happen randomly (even “high quality” ones, if anything I’ve had it happen more on them than cheap $0.10 ones). Usually due to its calibration failing randomly.
If it doesn’t fix up after a restart or two, then it may be defective. NodeRed only reads what it is, does no changes to it. That’s what the actual chip is reporting and you can probably verify that the humidity level is suspiciously off as well, and it will show that in the app and slicer.
Got it, I restarted and everything is back to normal. I almost never turn the printer off due to constant printing day and night, probably something went off like you said.
Also question for you, so I’m running some automations allowing google home speaker to announce whenever there is an error on the printer, I’m working with the HMS error value [sensor.x1c_mybambu_hms] for this automation the problem is that any notification on the printer changes the HMS value to 1 even first layer inspection. Any idea how to read only true errors? I thought fail reason would be the data point I should be checking but I don’t think it ever changes.
The value in my nodered for HMS is a count of HMS errors - not the number of any particular error. This was because you could have multiple at once and individual sensors wouldn’t make sense.
Look into the attributes of the sensor - if you have 1 or more HMS errors, the error code and a link to the wiki page for that error will be there for each one. Note: Not all HMS errors have a wiki page yet, and doing a named mapping of them was sort of impossible since some aren’t documented yet even in the slicer I think.
Anyone else having an issue connecting to the MQTT of the X1CC all of a sudden?
I have not made any changes in weeks and it always worked but there was the recent firmware update…
I’ve rebooted HA and the X1CC and checked the IP & ports in Bambu, HA, and pfsense.
For the basic flow, I changed all the change nodes to functions so in theory it should be compatible with the P1P now.
For the advanced flow, I sped it up, added a way to fetch print material type (via majority) for the DB, and a quick edit to the database schema (it will update if re-imported dw). I also made it such that it looks in the cache folder properly too, and if you have the issue of bambu studio sending prints to internal and not sd card, enabling the SD Card caching on the printer will fix it at least for the FTPS flow to work. Grafana dashboard also has a minor update.
Collected all the bambu related guides into a tag here:
When I finally get the parts for my AMS lighting mod, I will probably make a guide for that too and a mini importable flow that can “attach” it to the printer device.
I also have in mind for the future a way to add a camera entity if provided with a url to the printer, so you can add a URL from a third party camera, or a local url of a virtual cam etc. It will be a “you set it up however, just give it a URL” basis. I plan to put this in sometime in a few weeks after I get it working
Your guide states “Optional: A domain name pointing to a server you control, such that you can expose just your NodeRed instance to the internet (Only a /get/media prefix path. Block everything else).” I think this is a bad advice.
Thanks for the link. I am personally aware of the risks and did look into it beforehand, and my own instance has quite a few security measures in place (multiple layers of auth, everything dockerized and separate, RProxy, and only one endpoint ever allowed outside of localhost).
I will edit the post to recommend implementing a different approach, but since hundreds exist, I won’t specify an exact one to use. I will also put in some warning about exposing stuff to the internet, was in my head just missed it for that one post since it was more in the “Advanced” flow of things.
Edit: Updated with warnings and a link to that FAQ. Thanks again, completely slipped my mind to mention that warning.
@WolfwithSword Im trying to get the advanced configuration working but am having a heck of a time getting it working. Im running HASSOS in a vm and have the Node-Red add-on installed. Where do i create the /data/fetched folder? If i bring up the file explorer addon i can find a node-red folder, i added the /data/fetched in there but its not adding any images there. Also, im not entirely sure postgress is receiving any data, in grafana all that is being displayed is Total Costs(Energy) everything else says no data. Here is what my flow looks like
I don’t run HASSOS so I don’t know the addon structure but the /data/fetched folder should be inside the docker container of nodered (addons are just fancy docker containers afaik). I don’t know if it shares it with HA or not but, it needs to be created at the root level for nodered. Alternatively, you could always change it to any other folder path, just make sure all references to it get updated too.
Worst case scenario you can maybe make a node that will pre-make this directory early in the flows just in case.
Looking at your flow, you have the Kwh and Energy Rate stuff working - so that should be pushing into postgres (it will affect total and idle costs yes). Everything else looks like is has not run even once (it would say something underneath if it did). So it looks like the When Print Starts/Ends or Pause/Resume has not been triggered yet. This could also be why you don’t have an image (The FTPS functions didn’t run either, they still say “Ready” not “Finished”)
@WolfwithSword i will have to figure out the path thing. Im currently testing /config/node-red/data/fetched. I noticed that some of the data filled out after a print ended and i started a 2nd print but still nothing print related going into postgres. Also, there are a couple errors on the side that popped up that i have no clue what they mean.
That error means that the Parse Amt function failed - which means you had a print that was failed and it tried to fetch the print amount but couldn’t, likely because no row existed in the DB for that print as it didn’t run beforehand when it first started. You can ignore it for now unless it comes up again after the other issues are sorted.
So the rest of your data seems like it filled in - suspicious that you managed to get a screenshot with it in a “PREPARE” state… usually that state lasts for only a few seconds, tops, before you start a print…
Remember the directory is from NodeRed’s perspective, not HomeAssistant’s, just in case.
If you trigger a new print, when it goes to RUNNING state, it should run the nodes as expected to first enter it into the DB, and then run the top part for FTP fetch (which still hasn’t run in your case).
@WolfwithSword interesting, i hadn’t even noticed the preparing state. I had clicked the start button on a print and then took a screenshot so i must have impeccable timing. I hadn’t thought about the path being in NodeRed’s perspective so modified it to /local/lib/data/fetched and will see what that does after my print finishes.
This is an X1C
Screenshot attached showing it running now as well. If i restart the NodeRed addon will that kick off the whole flow again or will it only start on the beginning of the running status?
Only kicks off when the status transitions to RUNNING.
How are you updating the path? Because it’s used in several nodes, just in case you have some mismatching.
If you add a new “Inject” node and link it up to the top “delay 1s” node, deploy then click the button on the inject, it will force it to run the top part so you can test without needing to do a whole print - it will likely fail on the postgres part if it didn’t initialize it yet though.
? also dropped the humidity by 10%, i know for a fact i don’t have 12% humidity in there. This suddenly just happened, I didn’t change anything in nodered.
