Darn it, we’ll never know if the cat gets reunited! It was a fun and unique, if too short, game.

The ideal case for me is that I don’t need HACS at all. My experience has been the same - I’ve happily been able to switch to core HA components and stop using HACS ones. It’s great to see HA is not idle with success, they are continuing to make new features even when backwards compatibility may break.

I love this feature too - never having to worry about filament running out and using up the last bit of every spool is so handy.

It’s not as much as you might think, plus you have to purge to switch filaments with a single nozzle design. I would argue my Bambu saves filament on the balance because print failure is so low.

Simple - I don’t worry about it at all, I just load up a second spool of compatible material and let the printer switch when the first spool runs out (X1C with AMS).

Interesting! I haven’t had issues with ABS at stock temps in my X1C - 90C for the build plate - and I print a lot of large flat ish designs. I have had more trouble with PETG warping, and for HIPS I have to crank up the first layer to 110, then 100 for subsequent layers of it won’t stick to the Engineering Plate with glue stick at all.

My chamber temps do tend to be a bit lower, since I have an exhaust fan hooked up the carbon filter fan output to vent outside since ABS and HIPS fumes are nasty.

But yes, I’ve found 10C or so can make a huge difference when things do go south, it just hasn’t been an issue on my X1C for ABS, fortunately. Interesting to see how much a towel improves your chamber temps though!

Overall I love my X1C, one of the best decisions I made, don’t miss my old kludgy FlashForge Creator Pro and all its quirks one bit.

Heh, typing YAML anywhere is squinty business. :⁠-⁠)

After watching the Gamer Nexus video of what’s practically a warranty scam by Asus, I’d never buy one and may never buy Asus again if that’s the way they treat customers. I have a few of their ROG components in my system and from what I see they are not as great as they were 30 years ago.

ESPHome is amazing - there’s so much you can do without writing a single line of code.

I have built a few projects around the platform - a boiler monitor that tells me temperatures and state of zone valves, an energy monitoring system tracking electricity usage and solar export, and a hot tub mod that inhibits the heater to reduce grid import and maximize self consumption of solar. They have all been rock-solid stable.

ZHA here. I picked it since it’s a bit easier to set up with less bits. It works for me, so I didn’t see a reason to change it. I have done channel changes a couple of times with no issue - maybe I just got lucky!

I have not encountered this with my Sonoff Zigbee plugs, for whatever that is worth (US split phase). I also haven’t put large appliance loads on them.

I 3D print up a custom one, sized for each project.

Yep, it’s because of that proprietary and “every device must be licensed” nature of Z-wave that I use Zigbee devices - I’ll pick an open platform everyday over a closed one, even if it has limitations.

I’m glad it was helpful. They are great little controllers and ESPHome makes them so accessible for people like me who don’t really want to write code manually.

I don’t have an exact answer to your problem, but I do have a few ideas to think about. I’ve got a few ESP32 WROOM boards running in various applications, so I’m a bit familiar. So here’s my thoughts:

• I only plug the module into data USB (computer) for the initial firmware provisioning. After that, it’s 100% wifi and USB is only for power using a power supply, not the computer. And I do the initial provisioning with just the bare ESP32 - no breakout board, nothing plugged into GPIO. Get the device up on wifi with NO other configuration in the firmware.
• I use the “arduino” framework. I don’t know if that’s correct or really matters, I’ve heard it’s the same as “esp32dev” but I don’t really know. I use “arduino” because that’s what the examples used when I setup my first board.
• Is it possible that the sensor module/board is using the same GPIO that the USB UART uses? There is a lot of shared usage of the GPIO that you’ve got to be careful to work around. The dev tools will often catch this when you compile your firmware, but not always. Again, using wifi after the initial provisioning might be enough if it is sharing GPIO with the serial port.
• If you repower the ESP32 too many times rapidly it’ll boot into safe mode. You can change the settings on that, but you can also just work slowly - make sure the device is powered on for a few minutes to record a good boot in the flash. It outputs a message in the logs, so it’s handy to always be running the log command in a terminal while developing.

Hope that helps! They are a lot of fun to integrate with HA.

Sounds like it’s not actually running. Restart the hass server and check the logs, which is the only place you’ll see if a dependency is preventing it from starting.

Strange! Nothing jumps out at me as being an obvious problem with your setup. I’m doing something similar, though instead of rtlamr2mqtt (which I didn’t know about) I have a bash script run via cron that parses rtlamr output via jq and pipes that to mqtt (mosquitto), but there’s very little to it. I know the energy dashboard setup is picky about the energy recording entities.

Mine looks like:

state_class: total_increasing
unit_of_measurement: ft³
device_class: gas
friendly_name: Gas Meter

The name of the entity is sensor.gas_meter and the state is currently 113812 as an example.

Might be worth reading through GitHub issues for rtlamr2mqtt, including closed ones, if you haven’t already. Or maybe a hass restart? Can’t think of anything else.