I stick with MySensors for anything I cannot get power to (many nodes in hidden places around the house) or for simple low power sensing. I do have lots of ESPHome, but it basically requires running power or frequent battery changes so I only use it where I have power nearby.

Some of my nodes have been running for around 5 years on the same set of AAs, I don't think there's anything else that can achieve that longevity.

I do find it a shame that the main docs site here is very outdated and doesn't list any of the newer transports (PJON, CC1101, SX...) which gives the impression that the project is abandoned.

The CL got accepted and merged, so now MySensors officially supports CC1101!

Yes CC1101 is slower than NRF (the bitrate tops out at 250k, NRF starts at 250k), so I imagine this would increase
power consumption a little simply due to the longer airtime. However idle power consumption is comparable.

Penetration is certainly better, I have been running an NRF network for nearly a decade, but wanted to add a 433MHz network due to wall penetration issues, hence this feature.

I finally got around to creating a PR into the official repo, as it's been running reliably for some time so I believe it's ready.

The NACK status suggests that the response isn't getting back to your node. Perhaps something in the build config on the gateway is different to what you built the nodes with? Debug with #define MY_DEBUG_VERBOSE_RF24 perhaps.

Although, in your earlier post it seemed electrical issues caused your problems. Perhaps you're getting the same again, or the new OS does something to make it flaky again?

	Sent Message
Sender: 0
Last Node: 0
Next Node: 2
Destination: 2
Sensor Id: 255
Command: INTERNAL
Message Type:I_FIND_PARENT_RESPONSE
Payload Type: P_BYTE
Payload Length: 1
Signing: 0
Failed uplink counter: 0
Status: NACK (OK=success, NACK=no radio ACK received)
Payload: 0

I wanted 433MHz support to improve performance in an environment challenging to 2.4GHz, so I bought a bunch of cheap CC1101 radio modules and set about writing a HAL driver for this chipset. I probably should have bought some RFM69 modules, but I wanted the challenge of supporting another popular radio.

I took inspiration from some of the other radio drivers, and now have a fully featured driver that is very stable and I have a small network of nodes running nicely now. Nodes are AVR and the gateway is ESP32.

Power consumption is very similar to the RF24 radios (~20mA on full power xmit and a couple of uA in sleep). It also includes adaptive power control to automatically set TX power to just the necessary level.

My fork with cc1101 branch are in my repo, I have also added some documentation (some AI assistance here as I got lazy) . I've gotten the code pretty clean but probably still has a little development cruft left in it.

Would there be any interest in merging into the core?

Happy to take feedback, PRs, etc.

@Michiel-van-der-Wulp

An alternative is to do pullup via an output pin. So connect the switch like this:

D2 --- 47k --- D1 --- reed switch --- GND

Disable D1's pullups. While sleeping set D2 low to eliminate all power draw, then after wakeup you can set D2 high, wait a few ms and then measure D1. Once done, set D2 low again.

You can't do interrupt based sensing this way but works for polling.

I've been doing an experiment based on my custom board (https://github.com/buxtronix/mys-pro-mini) which is essentially an Arduino-pro-mini compatible pinout with NRF radio and SHT31 temp/humidity sensor built in.

It can take a CR2032 directly on board.

I've been running two identical sensors, the only difference being that one uses the INTRC clock, and the other uses an 8MHz Xtal. Update rate is about 1/min.

As you can see, I'm nearly 6 months in and I think I should be able to get to a year. Interestingly, there is no notable difference in battery between the two clock sources - it's otherwise been widely believed that xtal consumes more power than intrc.

The only low-power prep I'm doing in the code is to disable the ADC and set all unused floating pins to output mode. Standard arduino bootloader, BOD disabled.

Confirming also, I have about a dozen nodes around the place, all running off 2xAA batteries and all of the DS18B20 devices have no problems with this supply voltage, even when they are down to 2.8V they're still reporting reliably.

@Boots33 I haven't done a writeup of mine, perhaps I should fish it out of the pool sometime and get some photos.

The DS18B20 has a tiny standby current, something like 750nA. Even with 30 second poll intervals, I'm finding my sensors typically get near-shelf life from the batteries.

The physical setup is pretty basic - just a Pro Mini, battery, radio, and ds18b20. There's no circuitry for regulators, dc convertors or battery sensing. Of course I did remove the onboard regulator as it will draw power from the 'out' pin.

One thing I had to do was reprogram the fuses - you may find the Pro Mini comes with the BoD fuses set to like 2.7v. You can set it down to 1.8v so you'll get much longer life out of it. The effort is worth avoiding the hassle of more frequent battery changes.

Battery level sensing uses this VCC library: https://github.com/Yveaux/Arduino_Vcc

Nice project! I did one also with the same original thermometer. A couple of differences with mine:

• I used a DS18B20 which can run at a much lower voltage, so my batteries can get to about 2.0v before problems happen.
• No boost converter, everything runs straight of 2 batteries so the part count is less as well as avoiding losses in the converter.
• Battery voltage measurement is via the Vcc library which uses no external connections to the arduino, but is accurate enough for this use case.

In the past 5 months my battery voltage has stayed at around 2.97v.

For those looking to 3d print a case for this, if you cant find the right sized ducting, I designed one thats unobtrusive:

https://www.thingiverse.com/thing:2418194

All of the ducting near me is a bit too slim to fit sensors based on this, so I decided to design and print a case instead.

Does the trick nicely, and I also chose to use proper AA battery clips to retain a good connection, as the cable-tie battery assembly wasn't holding well for me!

On the Thingiverse page I have a link to the original OnShape doc.

https://www.thingiverse.com/thing:2418194

Thoughts, suggestions, etc will be much appreciated!