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.

I think Bambu is taking a reasonable approach - allowing people to do what they want, with the understanding that you can’t have it both ways, so you are either in the closed ecosystem with support and warranty, or not.

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.

This isn’t an issue with hackers though - this is people legitimately using the devices that they paid for with Home Assistant and other automation systems.

Yeah, the new logo is terrible, only takes up 1/2 the icon. I’ll just suck it up, personally, but I don’t know how they thought this little icon is an improvement over the old one - it’s not. In any way. Ah well…

You can try adding a brim (or a raft if that doesn’t help) and see how that goes - tall and skinny models can require some extra bed adhesion to be stable, and that can affect the very top if the model is moving enough for the extruder to hit it. Worth a try…

I have a couple - one doorbell cam and an Argus Pro. I don’t really integrate them with my HASS setup though - haven’t found a compelling reason to do so. Avoid the battery powered cameras like the Argus Pro though - nearly useless (poor object detection, no RTSP, slow to connect, no HASS integration).

I switched out three Honeywell TCC thermostats in the spring with Ecobee. All in all, the Ecobee units are great and work well with HASS. I use the cloud API integration and have some automation that kicks set-back in a bit quicker than 2 hours like the t-stats do natively when we are out of the house.

The only regret I have is I bought the higher end model, but should have bought the cheaper ones - I don’t (and won’t) use the built-in Alexa, don’t need the C wire kit, and the VOC/CO2 sensor is garbage.

The remote temp/occupancy sensors are great and do help balance out temperatures when the t-stat doesn’t cover all rooms very effectively.