Winter time is tinker time!

This is a compact environmental sensor node with an E-Paper display. My goal was to have a decent screen-to-body ratio with a simple and minimalistic display, easy to read from a distance. It is the first design in which I did not use an ATmega MCU. It is also the first time that I used KiCAD instead of EAGLE, soldered no-lead SMD components and worked with an EPD.

• It features a SHTC3 sensor to measure temperature and relative humidity and a VEML6030 to measure the ambient light, so that I can toggle lights or other appliances in the room based on temperature, humidity or light conditions.
• I have also added a MEMS sensor (LIS3DH) to auto-detect the device orientation and rotate the EPD image accordingly and / or detect tap events to toggle between different display modes / data sets.
• It can be powered directly from a 3V source or use the optional 3.3V boost circuit which accepts 1.5V or 3V sources.

I finished soldering and testing all the components today and just started programming the rough "framework". Looks promising so far! But still lots to do, including finalizing the 3D printed enclosure. This is how it is supposed to look in the end:

Since I already (half-heartedly) posted drawings of some RFM modules I created a while ago in another thread, I might as well put a little RFM69 / RFM9x infographic or cheat sheet together and share it with everyone. It's supposed to give beginners a quick overview over the available MySensors-compatible HopeRF modules.

If you guys mind that I included the MySensors logo and mascot, please let me know and I'll remove it ASAP.

I just got my first NRF5 running. I'll note how I got it working in case any of you guys still have troubles:

Setup

• OS: Windows 10
• Programmer: STM32 Blue Pill with the Black Magic Probe firmware
• NRF5: EByte E73-TBB dev board with a E73-2G4M0S1B (NRF52832)
• Environment: PlatformIO

Instructions

Load the Black Magic Probe firmware with stlink as the probe host onto Blue Pill. You can follow this guide.

Connect your new BMP to the NRF52 module:

BMP	NRF52	Serial Port
3V3	3V3
GND	GND
A5	SWDCLK	GDB Server
B14	SWDIO	GBD Server
A2	RXI	UART
A3	TXO	UART

Note: A2 and A3 are not required for programming. This is how you'd wire up the BMP for "classic" serial debugging. You can use the BMP both for programming and serial communication - no need for a second FTDI module.

Using the GNU Arm Embedded Toolchain, run arm-none-eabi-gdb in a console and enter the following commands to unlock the NRF52:

target extended-remote BMP_GDB_SERVER_PORT
mon swdp_scan
attach N // N = number of "Nordic nRF52 Access Port" if there are several
mon erase_mass
detach

From the two serial ports the BMP provides, you want to use the GDB Server for BMP_GDB_SERVER_PORT above. If Windows only provides generic names for both ("USB Serial Device" or something), the one with the lower number should (usually) be the right choice. If not, try the other one.

Windows users also must prefix the port with \\.\ if the number is double-digit, e.g. \\.\COM13.

Now you can start uploading sketches the usual way. Here's my minimal PlatformIO config:

[env:nrf52_dk]
platform = nordicnrf52
board = nrf52_dk
board_build.variant = generic
framework = arduino
upload_protocol = blackmagic
lib_deps = 
	548 ; MySensors

And a minimal test sketch for MySensors:

#include <Arduino.h>

#define LED 17

#define MY_RADIO_RF24
#define MY_RADIO_NRF5_ESB
#define MY_NODE_ID 182

#define SKETCH_NAME "NRF52 Test"
#define SKETCH_VERSION "0.1"

#include <MySensors.h>

#define CHILD_ID 1
MyMessage msg(CHILD_ID, V_VAR1);

void presentation()
{
  sendSketchInfo(SKETCH_NAME, SKETCH_VERSION);
  present(CHILD_ID, S_CUSTOM);
}

void setup()
{
  pinMode(LED, OUTPUT);
}

void loop()
{
  static uint8_t num;
  send(msg.set(num));
  ++num;
  
  digitalWrite(LED, HIGH);
  wait(5000);
  digitalWrite(LED, LOW);
  wait(5000);
}

Works like a charm so far! Now, if you please excuse me, I have a whole new microprocessor family to explore. Fun times!

It's great to see that you are putting in the effort to thorougly test and optimize your setup. I like that!

Now, I'm also not an EE myself - in fact, I consider myself as a beginner still, so please correct me if I'm wrong. The large (electrolytic) capacitor not only provides a good portion of the juice when it is quickly needed to keep the voltage level up, e.g. if the radio starts transmitting - it also smoothes low-frequency changes in the voltage, but their high-frequency characteristics are rather poor. To also decouple high-frequency noise, you'd want to add a small (ceramic) capacitor, typically 100nF, aswell. Together they provide a smoother voltage than just a single capacitor would. If the larger of the two is 10, 47 or 100 µF shouldn't matter too much, as long as the power source is able to keep up. Of course, if you go further into the details, there's much more to it.

I provide all my NRF24 nodes with (at least!) 100µF of bulk capacity via electrolytic capacitors - even if I'm heavily space constrained, like on tiny coin cell based nodes. I also always add a 100nF ceramic as close to the radio as possible and usually also an additional 10µF ceramic right next to it. This setup is working great for me: my "NACK rate" is usually below 0.1%. For example, my outdoor weather station has sent 5072 messages over the last seven days, of which four failed to transmit initially (< 0.08%).

I monitor the reliability of my nodes by simply checking the return value of send() and sending an error count if the transmission failed (ensuring that this message is successfully sent, or else I retry until it worked). All data is stored in a time-series database, so I can simply query the number of data points in a specific time frame as well as the number of reported errors.

Short answer: unless you have absolutely no space left for an electrolytic capacitor, there's no reason to not use one.

Long answer: Using an electrolytic capacitor or not when running off a CR2032 was a huge question for me when I was designing my window / door sensor nodes, because I assumed that their leakage current would be higher than the whole circuit consumes during sleep, resulting in a much lower battery life. The first thing I did was soldering up some prototypes (m328p, generic nrf24), one with a good quality, branded electrolytic capacitor, one with a random chinese cap and one without one and installed all on the same door, so I could compare them. I kept them running for almost a year until recently.

Unfortunately I lost my InfluxDB instance with the recorded data, but here's the gist: The units with a capacitor didn't drain the coin cell faster than the one without. In the end, the delta between the three batteries were merely 30mV, which is nothing considering the runtime. They're still at ~3.05V. Whenever I looked at the graphs to see how reliable they were, I couldn't find any issues - if they triggered a state change, they all successfully reported the event. Then again, they were installed on the door of the same room the gateway was in.

But here's the catch: When I received my custom PCBs, I installed two sensors on the same window on the other side of the house, one with and one without a capacitor - again, to compare them, but this time in a "real world" scenario. With #define MY_RF24_PA_LEVEL RF24_PA_HIGH, which is the default setting, the node without the cap failed to reach the gateway reliably, while the other one had no problem at all. Switching to RF24_PA_LOW resulted in both units unable to communicate with the gateway, they were simply too far away. Contrary, keeping the PA level up and soldering a 100µF capacitor on, solved the reliability issues of the second node. This effect might be even more noticeable, the further the coin cell is discharged.

So yes, there is a use for buffer capacitors and no, there's no reason to fear the "large leakage current" of electrolytics, unless you use old stock from the 90s or ones of dubious quality (I posted some more information and links to literature further down in this post, if you're interested). They provide stability in case of sudden current spikes (e.g. when the radio starts transmitting), at literaly no cost. I can recommend the Nichicon UMA/UMR capacitors if you're looking for a small footprint - 6.3x5mm for 100µF 16V.

I meant to post a detailed report on this topic for a while now as a follow-up, but didn't get around to yet. Anyway, I hope this was helpful.

I'm sorry to hear that you had such a disappointing first contact with MySensors.

I can't really comment on the issues you had with the ENC28J60 ethernet module and RPi zero gateway, as I haven't worked with those yet. But from my personal experience as a simple community member, I think problem 1 and 2 are due to your hardware selection not being very popular and therefore might not be as well tested as others and a partially outdated documentation (you hinted at the Raspbian release which is currently two major versions behind, for example) may be the consequence of this. This should clearly be updated, no question. And I can totally understand your frustration if you continue to run from one issue into the next one like this. I think I speak for all of us if I say that I know how annoying and discouraging it feels.

But here's the thing: I don't think the devs and mods are to blame for this. While there is mainly a core team contributing to the project, MySensors is open and community-based. Those who contribute regularly and actively have most likely enough things to do, to also constantly worry about keeping the guides up to date and verify the compatibility of every third party library. As the project grows over the years, adding more and more components, functionality, transports and so on, it's getting harder and harder to keep an eye on everything. I guess that's where we all have to accept responsibility to point out wrong, outdated or ambiguous information to help and improve MySensors.

In this sense, I think it is very helpful to get critical feedback from someone who is just starting out and has a technical background. You have a totally different perspective than someone who is completely new to it and also to the regulars. The former lack the expertise to identify and then express their problems when they hit a roadblock, while the latter may take specific things for granted and just know where they get their information from.

I just had a closer look at the wiring guide - which is part of the third problem you mentioned - and noted that there is indeed room for improvement in some places. Things which I've never noticed before because I didn't feel like I needed more information. But on second thought, yeah, that's because I've been through this before and gained knowledge along the way I now take for granted. For example, while the guide does recommend to use capacitors, it may not be communicated prominently enough - especially considering, that a lot of NRF24 troubleshooting threads in this forum seem to be caused by noisy signals / missing caps. On top of that, a list of (dis-)advantages for every radio type (range, reliability, power consumption, frequency, ...) might be a good addition to give beginners an idea what they should choose, because the radio introduction doesn't elaborate on this topic either. Maybe also a list of NRF24 modules which are known to be less troublesome than the common black one might be helpful.

I don't see the pin-to-pin wiring diagrams between Arduino and radio as a problem though. I always perceived MySensors as a beginner friendly platform and as such I understand why it is shown like that. It's the basics. You don't need more to get started, but of course, when you dig deeper and your expectation rise (or are high from the beginning), there's much more to it and you start wondering where to go from there, how to improve the signal quality, etc. Maybe there's room for an "advanced follow-up" to the basic guide, which goes into more detail.

As a personal consequence, I'm happy to take a closer look at any guide I'm familiar with and try to figure out if and how they can be improved. But I honestly don't expect to find a ton - without the intention to downplay your personal experience, I don't think it is representative for the majority of users - because the guides are generally in a good state already.

Let's not forget that MySensors has hugely lowered the entry barrier to IoT and home automation for countless people, which wouldn't be possible without the extensive contributions from the devs and every community member, who is actively helping. I invite you to participate and help to improve the project as a whole. Your input is very welcome.

---

Another general idea I just had is to add some kind of "I just made this and it worked / I tried to make it and it didn't work [because,... (optional questionaire)]" on every guide / article to get a feedback about its current state.

Wow, what a journey it was! As you might know, I ordered my first batch of PCBs at the end of November 2018. At the end of February 2019, I still didn't receive them so I contacted the manufacturer. After some back and forth they agreed to produce and ship my next order for free. In the beginning of March, I placed a new order with the "new revision" of the sensor. This time it took less than two weeks to arrive.

And there it is: My first proper build!

Banana One Euro for scale.

I'm quite happy with it. The circuit is functional and SMD soldering turned out to be a lot easier than I imagined, even without any prior practice. This gives me a decent confidence boost in designing and soldering future projects.

The board fits neatly into a 3D printed enclosure (55.5 x 27.5 x 11 mm). No mounting screws necessary. The magnet is seamlessly embedded in a tiny single-part enclosure (11 x 8.6 x 4.8 mm).

The combination of the DRV5032 and a 5x3mm neodymium disk magnet is perfect. The window is considered "open", when the gap between both enclosures is 8mm or more, and "closed", when the gap is at most 4mm wide. Awesome!

But there are also bad news...

You might have already noticed that the image above shows an ATmega328P, not an ATtiny84. But why? There are two issues with it:

• The ATtiny84 is lacking some hardware features, or has them implemented in a different way than the ATmega328P, and MySensors makes use of them. The results are compiler errors. For example, MySensors uses SIGRD (Signature Row Read) to retrieve a unique hardware ID for the device and EIFR (External Interrupt Flag Register) to clear pending interrupts. Unfortunately, this seems a little bit too advanced for me to address with my current knowledge.
• The ATtiny84 provides SPI functionality through USI. If you want to use the SPI protocol to communicate with other devices (a radio for example), as opposed to programming the chip itself, the MISO / MOSI connections apparently have to be swapped around (I didn't test this yet, but DO is on the same pin MISO and DI on the same as MOSI). This means, that my ATtiny84-based PCBs most likely won't work unless I cut the MISO / MOSI traces and rewire them with some jumper wires. Pity!

Since I have 25 ATtiny84A-SSUs laying around, I would still love to address these issues some time in the future. Without MY_DEBUG, the program is ~7950 bytes small and fits on the ATtiny84. 512 bytes of EEPROM (MySensors seems to use up to ~410 bytes) and another 512 bytes of memory (the program uses ~350 bytes) seem to be plenty, too.

What I learned, what I would change

Still, I call this project a success so far and I learned a lot in the process. I want to conclude this update with a list of lessons I learned, things I would change or might add in a further revision.

Lessons learned

• Don't reinvent the wheel. When I first started, I wanted to do everything myself, but I quickly realized that's not the right thing to do, especially if you're new to it. Yes, you will learn everything from the ground up, but you won't ever finish anything satisfactorily. Making use of tools like MySensors, on which many smart people worked for years, allows you to learn while doing practical things and keeping your motivation high. But don't blindly copy & paste either. Use it as a foundation.
• Don't rush it. Research thoroughly, read the fluffing manuals. It really helps to plan ahead and make yourself familiar with the technical and environmental constraints and requirements of your project, the characteristics of the components you want to use, and so on. Overall, I think I did well and have been amply rewarded with a fully functioning ATmega328P-based device. But at least the SPI issue of the ATtiny84 could have been addressed before ordering any PCBs if I wouldn't have been so naive to blindly believe that it would "just work".
• Don't freak out if you accidentally create a solder bridge or if a component slips out of place. Take a deep breath, apply some flux and try again. You will fix it.
• When you are compiling your program, make sure to set a proper CPU clock frequency via F_CPU or else you might end up in an infinite loop of trying to fix things that aren't broken. Whoops!

Possible changes, ideas for further revisions

• To allow more flexibility regarding the choice of components, I'd like to include a pad for a MLCC that could optionally be used instead of the electrolytic capacitor. It would also be great to allow the installation of other coin cell holders with a different footprint.
• A basic reverse polarity protection would be great, but I need to find a solution first, that doesn't suck the battery dry while the device is sleeping, nor causes a huge voltage drop.
• Get rid of the debug jumper I introduced with the first revision. When I thought about adding it, I was still working with a MySensors-free program, in which I wrote my own debug messages. With MySensors, I feel custom debug messages are not necessary and on top of that, debugging is toggled via a preprocessor directive (MY_DEBUG), which can't be toggled at runtime.
• Consider replacing the LED with a bi-color LED that can be driven using two I/O pins for success and error indication.
• Add RX/TX pins for the Atmega328P-variant. Besides allowing debugging without soldering thin wires directly onto the MCUs tiny legs, it would allow to upload a bootloader and enable serial programming, and thus OTA updates.
• Add a second set of VCC, GND and INT0 pads or pins where jumper wires can easily be soldered onto. Instead of using the hall sensor to trigger an event, one could attach a simple daughterboard for a button and turn the device into a smart home button / Dash button clone for on-demand automation.

I don't know if this is the end to this thread or not, but I want to thank you guys again for listening and helping. And who knows - maybe somebody can find bits and pieces in here that they can take away for their own projects.

If you ever designed a very compact PCB, you may have noticed that there aren't many options for small, reliable, yet easy to use temporary connections for in-circuit programming or debugging. While it is rather simple to replace various components like DIPs with a QFP, SOIC or SOP to save space, standard 2.54mm pitch plated through holes are usually the smallest feasible solution for beginners and hobbyists.

Note: There is a list of pros and cons at the end of this post if you prefer a tl;dr version.

Introduction: What is SOICbite?

Some month ago, I stumbled upon SOICbite. It is essentially just a PCB footprint, which is freely available for KiCAD and Eagle. The idea here is to repurpose a conventional SOIC-8 test clip as a programming connector and clip it to the PCB - much like an aligator clip. Those clips are rather cheap, starting at about 2 USD / EUR from China, but most notably, they provide a total of eight contacts in a very small area: compared to a standard 2x4 pin header, the footprint requires about 2.5 times less space!

By the way: you are not restricted to 8 contacts. There are SOIC clips with a higher pin count available as well - you would just have to adjust the SOICbite footprint accordingly.

Modification: Make it bite

Unfortunately, it is not possible to use a SOIC-8 clip on the SOICbite footprint without prior modification. The jaws don't close far enough to clamp themselves to the board. To get them to close further, you have to remove some of the plastic in front of the clip's hinge. This is best done with a small, straight needle file. A bit of sandpaper on a scraping card should work as well.

You need to remove enough material so that the little plastic teeth at the front of the clip can "bite" (hence the name) into the registration holes of the footprint. Keep in mind though: The more material you remove, the closer the opposing contacts get. So close, that they can eventually touch each other and cause a short circuit, if the clip is powered while it is not connected to a PCB.

The picture above shows a stock and modified clip side by side. You can clearly see how much closer the contacts get after modification. The red line marks where the plastic needs to be filed away. The blue lines are added to emphasize how straight the spring of the modified clip is. It is almost completely unloaded and it already has the tiniest amount of backlash. Luckily, the spring is just long enough to make it work with this particular clip.

Experience: Practical use

Although there is no real standard for pinouts, the creator of the SOICbite provides suggestions for different use cases:

Pin	UART	SPI	SWIM	SWD	ESP8266	USB	I2C	PIC ICSP
1	Vcc	Vcc	Vcc	Vcc	Vcc	Vcc	Vcc	Vcc
2	RX2	CS			GPIO0	D-		Vpp
3	TX2				GPIO2	D+
4	GND	GND	GND	GND	GND	GND	GND	GND
5	RX	MOSI/MOMI	SWIM	SWDIO	RX		SDA	DAT
6	TX	MISO		SWO	TX			AUX
7	CTS	SCK/CLK		SWCLK	CH_PD		SCL	CLK
8	RTS	RST	NRST	NRST	RST	ID

I'm not following any of these right now and assign the pins as I feel fits best for a certain PCB. This can be a pro or a con, whether you prefer a "foolproof" plug-and-play connection which is always the same, or enjoy the flexibility to adjust it to your needs and simplify routing. But since these clips are so cheap, you could buy a bunch and wire each to a standard-compliant layout for AVRISP, UART, SWD or whatever you need.

Routing the traces is obviously a bit more difficult than with a standard pin header, due to the compactness of the footprint and the five registration holes in front of the pads. There's only about 20 mil space between each set of holes. Depending on your DRC settings, the traces may be as thin as 6 mil, but even the cheaper PCB manufacturers should be able to do this properly.

Anyway - the spring clamps the contact pins onto the PCB and the plastic teeth register in the holes to keep everything aligned. The holes could maybe be the tiniest bit smaller in diameter for a little less play, but it's working great as it is and any smaller drill size could cause problems depending on the manufacturing tolerances, so it's probably best to not fiddle with it.

I'm using a standard 1.6mm thickness PCBs. While it may also work with 1.2mm boards, I can't really recommend this connector for thinner boards. As I've mentioned above, the spring of the modified clip is almost fully extended and at the very edge of getting loose. To use it on thinner boards and improve the clamping force overall, swapping the spring for a slightly longer one would be advisable.

For what it is though, the mechanical strength of the connection is rather impressive. The contact pins inside the clip have some spring to them, so they cling onto the pads even if the surface finish is uneven or the clip isn't perfectly perpendicular to the board. It doesn't fall off if you try to pull it out straight, you can move the whole assembly while it is connected and powered - no problem. But you can tilt the PCB out quite easily. I think it is certainly better suited for small and lightweight PCBs, which is fine, because those are typically the kind of boards, where you'd want to use a space-efficient connector on.

It's definitely not as robust as an interlocking socket-plug type of connector - you honestly can't expect that - but it is certainly on par with a spring-loaded pogo pin jig. So far I've programmed almost a dozen of nodes with it and kept serial connections open for hours while they were sitting on my desk completely unprotected and had no issues.

What I would recommend though, is buying a clip with an already attached wires, because it is a mess to properly solder flexible stranded wires onto the pins - there's only a very tiny gap between them. The following method worked best for me:

• Fan the pins out by carefully bending them outwards. This provides enough space to solder on regular 30 - 24 AWG stranded wires.
• Pull on a small diameter piece of shrink tubing over every second wire to avoid shorts later on - using different colors may help to ensure all wires are soldered in the correct order - and solder all four wires.
• Bend the pins back straight and secure everything with a larger piece of shrink tubing.
• Repeat the same on the other half of the connector.

Conclusion: Give it a try!

Is it the best option available for small-scale temporary in-circuit programming and debugging connections? Maybe, maybe not. It works surprisingly well and it can't get much more compact. It is reliable when handled with care, easy to implement into a design, simple to use and doesn't require custom built jigs, which makes it a great, easily accessible choice for hobbyists. It also has the benefit that it doesn't require additional permanently soldered parts on the PCB. And it's dirt cheap.

The primary downside of the SOICbite is that it needs to be at the PCB edge, which might not always be what you want. Modifying it isn't too troublesome and you can buy already wired clips if you can't be bothered to do it yourself.

There might be more straight-forward, professional alternatives which are equally space-efficient, like Tag-Connect or pogo pins, but they come with their own downsides. Their spring loaded contacts may were out and fail over time, they need to be pushed down into the PCB manually for the duration of the programming process or require a custom jig to hold it in place. Also, Tag-Connect cables can easily cost 50 USD / EUR.

I think the SOICbite is a viable option for simple, space-efficient temporary connections and I can totally recommend it for this use-case. I will definitely use it more often in the future.

TL;DR

To sum it up, here's a quick rundown of the pro's and con's of the SOICbite connector:

PROS

• Very space-efficient (2.5x smaller than a standard 2x4 pin header)
• Provides a reliable, sufficiently strong connection, comparable to a pogo pin jig, if some caution is exercised
• Doesn't require any permanently soldered parts on the PCB
• With prices starting at 2 USD / EUR, SOIC-8 clips are super affordable
• Higher pin-count SOIC clips are available, if 8 pins aren't enough

CONS

• The SOIC-8 clips must be modified to work, but it's easy to do
• It can only be used at a PCB edge
• Using thin traces of 5-7 mil width (depending on your design rules) to route between the registration holes might be problematic for some manufacturers
• It is not really suitable for thin PCBs (< 1.6mm), without replacing the spring

Where to buy?

I ordered a bunch of clips from different sellers on AliExpress. They all seem to sell the same model, at least in the lower price ranges. So it should be safe to get the cheapest offer you find.

Currently, I would recommend this set which comes with an already soldered ribbon cable and two handy little adapters for just 2 USD / 1.80 EUR (plus shipping):
https://www.aliexpress.com/item/33058340727.html

This is the model I'm showing in the pictures above. It comes without wires, if you prefer that:
https://www.aliexpress.com/item/32953869303.html

This one can be wired up with regular DuPont wires if you prefer that, although it looks a little weak and flimsy:
https://www.aliexpress.com/item/32908232000.html

If you don't trust AliExpress or eBay, I'm sure you'll find them at your prefered distributor aswell!

The availability of inexpensive commercial products surely is a factor for less interest in DIY solutions like MySensors. Chinese companies are flooding another market once again. Just look at Xiaomi's Aqara and Mijia range of products and their compatible clones. They offer at least a dozen of different sensors and actors in neat little enclosures with either ZigBee or BLE connectivity, many of which are commonly available for much less than 10 USD a piece in sales.

In this view I get frequently asked by friends and relatives why I keep "wasting" so much time building my own devices when I could just buy some like they do and integrate them into Home Assistant or HomeKit with the flick of a switch.

I always respond to them that - apart from privacy and reliability concerns against devices with a forced internet connection, as has already been mentioned by some of you - I actually enjoy the whole process from prototyping electronics to managing a home server. It's a hobby and I learn new things through it. Three years ago, I could barely read basic circuit diagrams - here I am, comfortably soldering self-designed all-SMD PCBs, enjoying programming so much that I branched out into other areas and started developing web apps. I can at least attempt to repair faulty electronics - and have been successful at times - instead of throwing them away and wasting resources.

The whole DIY process forces me to think about my requirements and constraints. To think about what I actually need instead of what I want or could buy to fill a hole.

MySensors is fantastic for someone like me. It is fairly accessible with commonly available components, with the option for much more powerful hardware, if needed. Wireless communication can be remarkably reliable. Other than ESP-based devices, MySensors nodes can be incredibly energy efficient for battery use. It's not polluting my WiFi, nor invading my privacy through cloud services. And although you might say it has gotten quieter in the forum, there's still always someone around to help if you're stuck. It's just that MySensors is strictly DIY, as @monte pointed out. You can't just buy a commercial device, upload a MySensors sketch to it and be done.

That's probably not the answer to the question where everyone went, but rather why not many new come in. Maybe it's a hindrance for new users these days? Because the "DIY aspect", that's now often obsolete, was just a necessary evil for many? Or, as my friends ask, why waste your time with that?

I guess you either have to have a specific mindset and interest to pick this up as a hobby with some dedication, or your requirements are so specific that no commercial product suits them, so that the pressure to DIY is high enough to bring yourself to do so. If not, the big home automation youtubers may show you the convenient way to quick satisfaction.

If I remember correctly, writing to the serial port takes about 10s / baud rate for a single byte. That's a little unter 90µs at 115200 baud (common for Arduinos clocking 16 MHz at 5V) or about 1ms at 9600 baud (1MHz for 3V or less).

Imagine we are transmitting two messages per wake cycle and print another few custom lines to the serial port as well, that may result in about 500 bytes total. This would then add another 45ms on a fast clocking Arduino (115200 baud) or 0.5s (9600 baud) - plus likely some overhead - to the time the microcontroller spends in an active state.

According to the datasheet (p.312), an ATmega328P clocking at 1MHz consumes about 0.5mA in an active state at about 3V. So, from here on, you could calculate how drastically (or not) an additional ~0.1 - 0.7s of active time per wake cycle would impact the runtime of the battery.

Since it's possible to run a node for a year or much longer off a set of batteries if it doesn't send lots of messages every few minutes, I doubt you would be able to notice a difference between disabling debug prints or keeping them.

It is usually much more important to keep the current consumption during the power down phase as low as possible, than shedding off a few ms of active time.

Yeah, companies want you to buy their own gateway to lock you into "their" ecosystem. Some ecosystems, like Philip's hue for example, at least allow you to add a limited set of third-party devices to their system. But generally, as long as the ZigBee devices follow the protocol, which most do, they should be able to co-exist in a single network - it's just that most commercial vendors don't seem to want that.

Luckily, as rejoe2 mentioned, there are open source ZigBee stacks like Zigbee2MQTT or the Home Assistant-centric ZHA, which allow you to manage all your devices from a unified UI / HA controller.

I personally use Zigbee2MQTT together with a Sonoff Zigbee Plus Dongle (powerful CC2652P) and have devices from various vendors connected. Philips hue and Innr LED bulbs, Osram plugs, some Chinese radiator valves, Xiaomi thermometers,..

There are websites that list which Zigbee devices are compatible with open ZigBee software stacks, with information about how to set them up, etc:
https://zigbee.blakadder.com/index.html
https://www.zigbee2mqtt.io/supported-devices/

@pikim No, I am not. My original plan was to deploy more and more RFM-based nodes as they seemed superior over NRF24 in general, but I realized that my NRF24 network was rock solid and reliable, so there was no need for the added complexity and cost to support and integrate another transport. Plans are made to change them.

That being said, I used the multiRF gateway for months without issues. The gateway operated as stable as the single transport 2.3.2 gateway. No issues at all, except with the automatic TX power adjustment (ATC) of the RFM transceivers, due to what I believe might be a timing issue within the library. I described the issue in this thread. Basically, the RFM nodes were not able to reduce their transmit power, unnecessarily blasting the environment and wasting battery power. Introducing small delays in various places was all it needed to work around this issue successfully, seemingly without adverse side effects.

This issue has not been properly remedied since the introduction of the multiRF gateway though. For all I know, it is still tekka's personal fork of the MySensors 2.4 branch and has not been updated, so any new fixes and features for version 2.4 since March 2020 will not be available to this fork, unless you manually implement them.

So I guess it is up to you if you prefer to use the multiRF gateway without all the mainline 2.4 changes, or the up-to-date 2.4 branch without the multiRF feature. It should not make much of a difference currently, according the the commits since the multiRF fork, unless you want to use PJON transport or deploy NRF5-based nodes.

I really wish that the development on MySensors revives, as it is feeling kinda stale at the moment. It would be a shame if this project got silently abandoned. I would be glad to help out wherever I can.

No, Home Assistant didn't render battery-powered nodes unusable.

I have never used the optimistic mode in Home Assistant, yet I'm able to achieve uptimes of more than a year with CR2032-powered (merely ~230 mAh) MySensors nodes. See here for an example. The temperature sensor I mentioned there is still working since April 2020, reporting every 5 minutes.

In which use case would the optimistic mode be necessary?

I mean, you have full control over the node's behavior. If you want to go as easy on the batteries as possible, you can put a node back to sleep as soon as it has sent a new measurement once, without waiting for any feedback. For more critical sensors (i.e. security-related) and actors on the other hand, you probably want confirmation that the data was successfully received and rather replace the batteries a little bit earlier, don't you?

@Marek If you only copy and pasted the above two lines into your config, then you got that error message because it is an incomplete configuration for the old, YAML-based MySensors integration.

A valid YAML configuration looks, or rather looked, like this:

mysensors:
  gateways:
    - device: mqtt
      persistence_file: '/config/mysensors.json'
      topic_in_prefix: 'mysensors-out'
      topic_out_prefix: 'mysensors-in'
    - device: mqtt
      persistence_file: '/config/mysensors_testing.json'
      topic_in_prefix: 'mytest-out'
      topic_out_prefix: 'mytest-in'
  optimistic: true
  retain: true
  version: '2.3'

You may be able to set the optimistic setting by adding something like this to your config and restarting Home Assistant. You may also need to delete your existing UI-based integration beforehand.

That being said, the old YAML configurations are not recommended (and apparently neither documented) anymore. When a YAML-based MySensors configuration is detected after a HA start, it will be migrated to the new UI-based integration automatically. Subsequent changes to the YAML config will be ignored.

AFAIK, the new UI-based intregration deprecated a bunch of configuration options and I think that the optimistic setting is one of them. I don't know of a way to set it using the UI-based integration, nor if it'll be carried over by importing an "existing" YAML config. The documentation of the MySensors integration may be incorrect / outdated here.

Hmmm. Unfortunately, that "connection lost" line is to vague for me to draw any conclusions.

Have you had a chance to look at the gateway's serial log when it lost connection to Home Assistant?

What version of MySensors are you running by the way? Maybe it's worthwhile to upgrade to 2.3.2 if it isn't already. Home Assistant is also up to date?

The next steps that I would take would be to ...

• Check that both MySensors and Home Assistant are on a recent version
• Watch the gateway serial log for any hints (using a remote debugging library or hooking it up to a server / RPI and writing the serial output to a file)
• Ensure that the power supply is fine and maybe even replace it temporarily, just in case
• Consider adapting the gateway sketch to MQTT (or even serial) and see if the issue still comes up

Well, MySensors doesn't care at all about units when you send a message. It gives you the freedom to measure and send whatever you like. Be it temperature readings as °F, °C, °K or even °Re.

Note that MySensors is just the communication framework. Everything else needs to be handled by you, the sketch developer. You handle the sensor interaction and - if necessary - do the required unit conversions manually or with the help of a suitable Arduino library. Just as you would in other non-MySensors projects.

Let's say you want to get the temperature from a BME280 sensor and use SparkFun's library to interact with it. If you only care about imperial units, call the readTempF() function they provide to store the temperature in Fahrenheit in a variable and send it to HomeSeer.

BME280 bme;
MyMessage msg(CHILD_ID, V_TEMP);
//...
void loop()
{
	// ... every 5 minutes ...
	
	float temp = bme.readTempF();
	msg.send(temp);
	
	// ... return to sleep ...
}

No controller configuration required, and that's totally fine. The vast majority of MySensors users would do it this way.

While MySensors doesn't care about units, as I mentioned above, it still enables you to check which system of units the connected controller wishes to receive using the ControllerConfig object. With this, you could write sketches which conditionally send different values for those users who use a controller with imperial units than those, who configured it for metric units.

BME280 bme;
MyMessage msg(CHILD_ID, V_TEMP);
bool metric = true;
float temp;

void setup()  
{ 
	metric = getControllerConfig().isMetric;
}


void loop()
{
	// ... every 5 minutes ...
	
	if (metric)
	{
		temp = bme.readTempC();
	} else 
	{
		temp = bme.readTempF();
	}
	msg.send(temp);
	
	// ... return to sleep ...
}

If I would use a sketch with a condition like this, it would send the temperature in °C to my Home Assistant controller, since it uses the metric system. For you, on the other hand, it would send °F to your imperial HomeSeer setup.

I feel like I gave you the same answer as above, just differently worded.
Still, I hope this makes it a little bit clearer for you.

@Karl-S Welcome!

If I understand you correctly, you only care about imperial units. In this case, simply send imperial units from your sensor nodes to HomeSeer or any other controller of your choice. There is no configuration required.

That being said, a controller can "tell" the MySensors network if it uses metric or imperial units, which the gateway will store as a isMetric flag in a ControllerConfig object. Any MySensors node can retrieve the controller config from the gateway, so that you can implement the logic to convert and send measurements in either one or the other unit.

This is helpful if you share sketches publicly in which you want to provide both metric and imperial measurements out of the box, so that nobody who uses your sketch needs to change a thing. But if you write a sketch for yourself, simply ignore the configuration and send imperial measurements.

@keithellis If reloading the integration from within HA can "fix" the issue at least temporarily, I assume that the log should at least give a clue on this. So the best way to troubleshoot such issues may be to activate debug logging in the HA MySensors integrations and consult the logs when the communication stops.

You may also try to remotely read (and store) the WiFi gateway serial output with a library like MyNetDebug.

@Sunseeker According to the Connecting the Radio page, D2 is the default pin for the CE signal for the NRF24. If you'd like to use this pin for I2C, you can free it up by assigning a different pin for the CE signal by adding this line to your sketch:

#define MY_RF24_CE_PIN pin

IIRC, all available pins should work for this purpose (D0, D3, D4). Just pick one and if it doesn't work, use one of the other pins. Please make sure to add that line before #include <MySensors.h>.

Welcome @gav!

The MySensors MQTT gateway subscribes to any topic matching this pattern: mysensors-sub-topic/+/+/+/+/+. The wildcards are (in order) node ID, child sensor ID, command, ack and type (see here for details on the protocol API). Based on that you (or your controller using automations) could publish to any topic with that scheme and the gateway will pick it up. It then constructs a MyMessage object and forwards it to the destination node (the node with the mimic panel, in your case).

For example mysensors-in/10/0/1/0/2 with a payload of 1 will cause the gateway to build a message that is directed to node ID 10 and tells it that there is a new value for its child ID 0, which we would like to set to 1 / true (the payload) and that the message is of type 2 (V_STATUS).

I'm not familiar with OpenHAB, but I assume it provides a way to send custom messages to MySensors. If not, you can always fallback to using "raw" MQTT as shown above.

In any case, make sure that you listen for the incoming message in receive() on the destination node. There is no automation in place for handling incoming messages. You have to make sense of it.

bool isActive;

void receive(const MyMessage &message) {
	if (message.getSensor() == 0 && message.getType() == V_STATUS) {
		isActive = message.getBool();
	}
}

void loop() {
	if (isActive) {
		// Do something
	}
}

Keep the receive() function as short as possible. Check the incoming message and assign variables or set flags here, but do all the time consuming logic inside the loop() to prevent locking up the node, causing recursive loops and such.

Note that the node cannot be put into sleep when it is expected to listen for incoming messages.

Hope this gives you an idea on how to handle such tasks using MySensors.