Best posts made by BearWithBeard

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.

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.

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!

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.

It took me a little bit longer to post an update, but I decided to spend some more time with my family and focused on another project for a while. Hope you've all had a good start into the new year!

I made quite a lot of changes to the PCB and incorporated ideas and suggestions from you guys.

As always - feel free to skip whatever section you don't care about or just read the headings to get a "tl;dr" version of the changes.

Schematic and PCB layout

Schematic

Top Layer

Bottom Layer

The routing around the Attiny's pins almost looks like I'm working with a single-layer PCB, but I can't use vias except for GND in this area as the coin cell occupies the whole backside (and several (inexpensive) PCB manufactures seem to be unable to make tented vias and cover them with a solder resist mask). I guess those fancy "spirals" around the left-hand pins won't cause any issues.

Trace width for GND and VCC is still 20 mil. All other signals are now 9 instead of 10mil.

There are some airwires visible between some of the VCC signals. I guess EAGLE doesn't understand that the four VCC through-hole pads of the battery holder are physically connected. If anyone could tell me how to deal with it, that would be greatly appreciated!

(And yes, yes. That lonely resistor on the back looks so sad and silly. But it's the position with the shortest routes and least vias I could come up with, so it seems to be the best solution.)

List of Components

• U1: Attiny84A-SSU
• U2: TI DRV5032FB or Honeywell SM353LT
• U3: NRF24L01+ SMD module
• R1, R3: 10kΩ (0805)
• R2: 680Ω (0805)
• D1: Kingbright 2 mA, 150mcd, 40 deg, red Dome-LED (1206)
• C1, C2, C3, C4: 0.1µF 50VDC X7R MLCC (0805)
• C5: 100µF 16VDC electrolytic cap (e.g. Nichicon UMA series)

I will focus on the Attiny variant for now

I prefer using the Attiny84 for several reasons over the Atmega328P for this project - it allows to make the overall device a little bit smaller, gives more options for routing signals and costs less than half of an 328P, which feels wasteful to use with most of its pins unconnected.

I will most likely go back into EAGLE and design a variant for the Atmega328P as well before I'm going to order PCBs the next time so that I get a batch of both anyway - but I don't want to continue working on two variants simultaneously while major changes are likely.

Ground plane on both PCB layers

As suggested by @Nca78, I've also added a ground plane on the top layer this time.

But I'm unsure if this has any consequences for the decoupling capacitors and their corresponding power pins. Doesn't it "break" their current loop? Why would it be considered bad if the plane would be VCC instead? (I definitely need some good reading on this topic.)

Status LED included

@Nca78 pointed out that there are SMD LEDs that can produce a bright spotlight with very little power.

Mouser doesn't seem to have any LED in their catalogue with a current consumption <2mA that's larger than 0402. So the one I chose to include is a 1206 dome-LED from Kingbright which reaches a luminosity of 150mcd at 2mA in a 40° cone. LEDs with similar specs seem to be easily available. I think that should do the job.

Added serial pins and a jumper

Originally, I didn't want to add a serial header at all, as it would take up way to much space on the PCB. But @mfalkvidd made me think about a simpler solution: Adding RX/TX pins to the already existing ICSP header.

This allows for on-demand debugging functionality via software serial if pin 12 is pulled high through the jumper. If the jumper is disconnected, pin 12 will get pulled down to ground and serial functionally will be disabled, going back to normal operation mode and reducing power consumption to a minimum.

At this point, I don't worry about auto-reset functionality, since the Attiny84 with its 8kB of flash memory hasn't enough space to fit a bootloader besides the actual program.
That's a consideration to take into account with the Atmega variant.

Increased distance between antenna and copper

The new design leaves much more space between the antenna of the NRF24 module and any part of the circuit (at least 5mm). The closest metal part will be a M2 bolt that attaches the board to the enclosure.

Using an electrolytic capacitor as a buffer instead of a MLCC

Well ... I went forwards and backwards many times whether to use an electrolytic cap or an MLCC. After all, I concluded using an electrolytic cap is the most sensible solution. Here's my (lengthy) explanation for it:

• (Large capacity) MLCCs are increasingly difficult to acquire and their prices are going up as well. There is no guarantee that I - or anyone else interested in this project, as private individuals - can get an affordable MLCC in a specific SMD package in a reasonable amount of time. Items that are in stock today can be sold out by tomorrow, with lead times of "53 weeks".

• The actual capacitance of MLCCs is largely dependent on the applied voltage in relation to its rated voltage (DC bias, some background info). This means that a 100µF MLCC rated for 10VDC might store a charge of only 40 - 70µF when supplied with 3V (average values I've gotten by looking through the online databases from murata and TDK). This would require the use of a MLCC that has a higher nominal capacitance or possibly, depending on the specific part, a higher rated voltage, which has its "sweet spot" at around 3V. But those cost easily 5 - 25 USD / Euro a piece. That's not sensible at all.

• Last but not least: Reading a paper from a German battery manufacturer ("Leakage current properties of modern electrolytic capacitors"), I concluded that using an electrolytic cap in battery-powered applications might not be as bad as one might think.

  AVX apparently released a paper very similar to this, but unfortunately it doesn’t seem to be (publicly) available anymore. Rubycon writes in a technical note that the specified leakage currents are higher than they actually are, “because it takes too much time to measure the true leakage current”.

  Summarizing, the specified leakage current in a capacitors data sheet is usually far above the actual operating leakage current that should be expected when a voltage is applied to the capacitor continuously. It is generally by a few factors lower than specified, even more so when the supply voltage is far below the rated voltage (TDK, p. 17) - for a 100µF 16VDC cap and a specified leakage current of up to 3µA that is supplied with 3V, the operating leakage current should settle between 100 and 250nA.

  Plus, my experiment with the two prototypes I mentioned in an earlier post seems to back the point that the leakage current of (decent) electrolytic caps isn't a huge deal in low power applications as one might think, since both devices seem to drain the battery equally.

Considering that 100µF 16VDC electrolytic caps with a total height below 5.5mm are - other than similar MLCCs - rather cheap and widely available, it seems reasonable to stick with an electrolytic cap as a buffer.

After all, the limiting factor regarding the total uptime of this device isn't the technology of the buffer capacitor - it's the self-imposed constraint in regards to the overall dimensions of the device, thus opting for a tiny CR2032 coin cell. Choosing a slightly larger power source will absolutely have a much bigger impact on the battery life as any kind of capacitor could have.

Yes, the best possible capacitor might increase the battery life by a few weeks or even two months - a CR2450 instead of a CR2032 would increase it by years.

For the sake of completeness, there are also specific "low leakage" electrolytic caps available like the UKL series from nichicon which specify a leakage current of less than 0.2µA after two minutes. Unfortunately, with a minimal size of 6.3mm x 11mm they are a bit too large for this project.

Moved the battery to the back of the PCB

Making use of the fact that I go back to using a electrolytic cap as a buffer, I can mount the battery as well as the cap to the back of the PCB - as well as the 90° angle pin header for the jumper that otherwise wouldn't fit on the board.

This makes the device ~2mm thicker (~9mm total thickness) than mounting everything on the top of the PCB (~7mm total thickness) but I can keep the board dimensions of 24mm x 36mm despite adding more components. Having all the thick components on the back also means that the hall effect sensor is as close to the front of the enclosure as possible, reducing the distance to the magnet.

The CR2032 can easily be replaced by a CR2450, which has a three times higher nominal capacity, without increasing the overall device thickness and only increasing the PCB height from 24mm to 27mm - I just have to commit to using a specific coin cell holder model to adjust the contacts on the PCB accordingly. Until then, I'll stick with the CR2032.

---

That's it for now. Your comments, ideas and suggestions are highly appreciated, as always. Thanks for your attention!

@berkseo said in What did you build today (Pictures) ?:

@monte said in What did you build today (Pictures) ?:

Or do you mean that they are discontinuing 1.54" displays completely?

Yes, I mean that these displays are no longer produced. And it is better to focus on new ones.

Just to clear up a potential misunderstanding: The 1.54" EPDs aren't going to vanish anytime soon. Only the GDEP015OC1 has been discontinued and the GDEH0154D67 may follow, too at some point.

But Dalian Good Display has just launched the GDEW0154M09 this month, which seems to be the successor of the GDEH0154D67 at first sight. There is also the GDEW0154M10, which supposedly has a better contrast due to a new manufacturing process. Waveshare seems to be still selling their version of the GDEH0154D67, but not any of the new ones.

I don't think you need to hoard them like other poeple hoard their live-long stock of toilet paper these days.

@Giovanni-Chiva You need the development branch (2.4.0-alpha) for multitransport. 2.3.2, which you are using, doesn't support that. Download here: https://github.com/mysensors/MySensors/tree/development

The graph above is from my oldest window contact that is still in service with its first CR2032. It has reported 2902 events in over a year (less than 8 wake cycles per day on average).

The second graph is from my oldest temperature & humidity node, also running off a CR2032. Since march 2020, it reported 180k data points (temp & hum every 5 minutes).

Unfortunately I didn't configure them to report the battery voltage back then, but I took a reading with my DMM right now: The window node reads 3.041V and the temperature node 2.993V. What I'm trying to show is that nodes can run for years with a CR2032.

The temperature node should be the most discharged CR2032 I have in use currently, so I have yet to find out at which voltage they stop working. But I think 2.8V should still be fine if you have enough capacity to counteract the voltage drop during transmission.

If the battery in your node died suddenly, I guess the node may have failed to sleep for some reason. I had this issue before a couple of times and I can only assume that the node lost connection to the repeater and drained the whole battery in a find-parent-loop.

Update (mid of Nov 21): The temperature & humidity node died a few days ago. It sent roughly 350k individual sensor readings over a span of 20 months. That's about the maximum lifetime I could expect with 12 wake cycles per hour.

IIRC, they are not recommended for new designs for at least a few years now. But you can still buy plenty of NRF24L01 ICs from Mouser or LCSC as of today.

CDEbyte still stocks various modules with NRF24 in their stores (see CDSENET, Cojxu and CDEBYTE - they all belong to the same company), but it seems like they are gradually drifting towards replacing it with the SI24R1 IC which are then labeled as the E01C series, as opposed to E01 for the NRF24. I don't own any of the E01C modules, but I'd assume that they still work better than the average unspecified Chinese NRF24 clone from eBay.

What would you recommend for new projects?

NRF5 maybe? They are fully fledged ARM-based SoCs with the NRF24-compatible transceiver included, but note that they are more difficult to work with than the good old Arduino + NRF24 combo. You'll need a compatible programmer, may need additional programming knowledge and I don't know if there are any through hole modules with pins available.

Look for the E73 series from CDEbyte. At least the NRF52832 is rather well supported by MySensors.

There are a couple of threads in the forum to get you going with NRF5, like the NRF5 beginners guide or the NRF5 platform overview. I also wrote a short guide how I got my first E73 to work using an STM32 as a Black Magic Probe.

If you're looking for replacement transceivers to use with ATmegas, look for RFM69 / RFM9x (LoRa). They have a potentially much higher range than NRF24 due to the lower radio frequencies they use, but need a little more effort to set up, notably because you have to manually solder an antenna to them.

I designed an infographic about the commonly used RFM modules by HopeRF a while ago if you need an overview.

@DenisJ With 120 wakeups per hour as per your calculator screenshot, you'd wake up every 30 seconds instead of once every 2 minutes.

You should easily be able to get more than a year of runtime with that hardware setup and the mentioned thresholds for temp/hum.

I know that some folks in here are using Home Assistant, but they may not all be visiting the HA website regularly. So I thought I'd share this info here.

They have published two security disclosures recently, informing us about security vulnerabilities found in third party integrations (including HACS, commonly used to integrate Alexa and such), which allowed an attacker to access any file that is accessible by the Home Assistant process. Be sure to upgrade to Home Assistant Core 2021.1.5 or later and all custom integrations as soon as possible.

More details as well as (all?) affected custom integrations can be found in the Home Assistant blog.

Oh shhhhoot.

So by switching from 328p8m to nanoatmega328p in order to fix some issues, I actually made it worse, because the latter sets F_CPU to 16000000L.

What an unbelievable oversight on my part. That explains why I had to monitor the serial output at 1/16th of the baud rate.

Overwriting the frequency in the config file with board_build.f_cpu = 8000000L did the trick. No need to adjust the SPI bus speed anymore. Baud rate set to 57600, monitoring at 7200 (1/8th, CKDIV8 enabled). All good!

Thanks for pointing that out, @tekka! I feel embarrassed, that I didn't notice that myself.

---

Small update -- after some more testing, setting board_build.f_cpu = 1000000L and #define MY_BAUD_RATE 9600 seems to be even better with CKDIV8 enabled. 1ms is actually 1ms and communication between nodes is way more responsive.

Powering the sensor node on, initializing, finding parent, presentation, etc,.. is now done withing 6 seconds instead of roughly 30 seconds.

Well this is just brilliant! And the timing couldn't be any better, as I was just about to conquer our garden with an army of RFM69 nodes.

For the last three days I was sending an incrementing number every five minutes with each an NRF24 and RFM69 node to a 3.3V Pro Mini MQTT gateway (W5500) without issues. Today I decided to flick the switch and route my existing NRF24 network through it, effectively replacing my trusty ESP MQTT gateway (which I will keep as a backup, just in case) and it's looking good.

RAM:   [=======   ]  74.7% (used 1530 bytes from 2048 bytes)
Flash: [========  ]  84.5% (used 25972 bytes from 30720 bytes)

Here's my basic sketch in case anyone might find it useful:

#include <Arduino.h>

#define MY_BAUD_RATE 9600
#define MY_DEBUG

#define SKETCH_NAME "Multi-TP Gateway"
#define SKETCH_VERSION "1.1"

// Ethernet & MQTT config
#define MY_GATEWAY_MQTT_CLIENT
#define MY_MQTT_CLIENT_ID "mys-gw"
#define MY_MQTT_PUBLISH_TOPIC_PREFIX "mys-out"
#define MY_MQTT_SUBSCRIBE_TOPIC_PREFIX "mys-in"

#define MY_MQTT_USER "username"
#define MY_MQTT_PASSWORD "password"

#define MY_IP_ADDRESS 192, 168, 178, 215 

#define MY_CONTROLLER_IP_ADDRESS 192, 168, 178, 220
#define MY_PORT 1883

// SoftSPI for radios
#define MY_SOFTSPI
#define MY_SOFT_SPI_SCK_PIN 14 // A0
#define MY_SOFT_SPI_MOSI_PIN 15 // A1
#define MY_SOFT_SPI_MISO_PIN 16 // A2

// NRF config
#define MY_RADIO_RF24
#define MY_RF24_CHANNEL 83
#define MY_RF24_PA_LEVEL RF24_PA_HIGH
#define MY_RF24_USE_INTERRUPTS
#define MY_RF24_IRQ_PIN 3
#define MY_RF24_CE_PIN 7
#define MY_RF24_CS_PIN 8

// RFM config
#define MY_RADIO_RFM69
#define MY_RFM69_NEW_DRIVER
#define MY_RFM69_NETWORKID 69
#define MY_RFM69_FREQUENCY RFM69_868MHZ
#define MY_IS_RFM69HW
#define MY_RFM69_IRQ_PIN 2
#define MY_RFM69_CS_PIN 9

// https://github.com/Wiznet/WIZ_Ethernet_Library
#include <Ethernet.h> 

#include <MySensors.h>

void presentation()
{
	sendSketchInfo(SKETCH_NAME, SKETCH_VERSION);
}

void setup()
{
}

void loop()
{
}

@NeverDie @waspie
I just found them on cdebytes eBay store for 10.87USD for ten units (1.08USD each) with free shipping. They are currently on sale with 20% off.

Also, LCSC sells them for 1.38USD a piece, but they only have 5 units at stock right now.

@mrhutchinsonmn said in 2nd sensor in sketch not showing up in HA:

MyMessage msg(CHILD_ID_A0, V_LEVEL);
MyMessage msg2(CHILD_ID_A1, V_LEVEL);
[...]
void loop() {
  [...]
  send(msg.set(sensorValue));
  send(msg.set(sensorValueA1));
   [...]
}

You are sending both sensor values with the same message, so they both get reported to child ID 0 and child ID 1 will never show up.

Change the second send function from
send(msg.set(sensorValueA1));
to
send(msg2.set(sensorValueA1));

Hi markjgabb,

#define BUTTON_PIN  3 
...
sleep(BUTTON_PIN, CHANGE, 0);

Assuming you use an Arduino, you can use two external interrupts (INT0 and INT1) on pins D2 and D3. But the sleep function requires the external interrupt vector, not the Arduino pin number. When you give it BUTTON_PIN (3), nothing will happen, since only INT0 (0) and INT1 (1) are valid external interrupts on ATmega328P-based Arduinos.

Instead, you could write sleep(1, CHANGE, 0), or preferably sleep(digitalPinToInterrupt(BUTTON_PIN), CHANGE, 0), which maps the pin number to the interrupt vector (or NOT_AN_INTERRUPT (-1) if invalid), if you want to wake up from D3 (INT1). 0 would wake up from D2 (INT0).

For more information, there's a good tutorial on interrupts by Nick Gammon. Also, chapters 12 "Interrupts" and 13 "External Interrupts" in the ATmega328 datasheet might be helpful.

@hek I think he means the project website to which the "Homepage" button links: http://www.mynodes.net/

This domain seems to be parked. Maybe it doesn't exist no longer? The last commit on the GitHub repo is from May 2017. SingleHub seems to be the successor, but again: last commit in 2017.

@NeverDie I don't think that SOICbite has ever been sold. It's just a conventional SOIC-8 test clip, that may need some modification, like filing away some of the plastic in front of the hinge or at the tip. I like the idea of this method because, apart from having a small footprint, they are super cheap (even less than 2 USD/EUR incl. shipping from China, like this one) and it doesn't require additional parts for every single PCB for a one-time job.

I'm currently designing a PCB (not nRF52840-related though) with the SOICbite connector on it and have some clips on order, to see how well it works. Might take a while until I reveice them, but I can report back as soon as I tested them.

I wonder - have you specified a protocol version for the MySensors integration in configuration.yaml? Because your HA log hints that you are using an older protocol which doesn't support V_TEXT. It is only available with 2.0 and higher and IIRC the notify service was also introduced with 2.0. The MySensors integration in HA defaults to 1.4 if no version is specified.

mysensors:
  [...]
  version: '2.3'

---

For the record - I just set this up myself and it worked fine. I'm using Home Assistant 0.107.7 (Docker) and MySensors 2.3.2

Relevant code in my sketch:

#define CHILD_ID_TXT 98
MyMessage msgTxt(CHILD_ID_TXT, V_TEXT);
void setup()
{
	send(msgTxt.set("#"));
	wait(1000);
	request(CHILD_ID_TXT, V_TEXT);
}
void presentation()
{
	present(CHILD_ID_TXT, S_INFO);
}
void receive(const MyMessage &msg)
{
	Serial.print("Received a message: ");
	Serial.println(msg.getString());
}

This is the HA log after uploading the new sketch to the node:

DEBUG (MainThread) [mysensors.gateway_mqtt] Receiving 179;98;0;0;36;
DEBUG (MainThread) [homeassistant.components.mysensors.gateway] Node update: node 179 child 98
DEBUG (MainThread) [mysensors.gateway_mqtt] Subscribing to: mysensors-out/179/98/1/+/+, qos: 0
DEBUG (MainThread) [mysensors.gateway_mqtt] Subscribing to: mysensors-out/179/98/2/+/+, qos: 0
DEBUG (MainThread) [mysensors.gateway_mqtt] Subscribing to: mysensors-out/179/+/4/+/+, qos: 0
DEBUG (SyncWorker_5) [mysensors.persistence] Saving sensors to persistence file /config/mysensors.json
[...]
DEBUG (MainThread) [mysensors.gateway_mqtt] Receiving 179;98;1;0;47;#
DEBUG (MainThread) [homeassistant.components.mysensors.gateway] Node update: node 179 child 98
INFO (MainThread) [homeassistant.components.notify] Setting up notify.mysensors
INFO (MainThread) [homeassistant.components.mysensors] Adding new devices: [<MySensorsNotificationDevice DevNode 179 98>]
INFO (MainThread) [homeassistant.components.sensor] Setting up sensor.mysensors
INFO (MainThread) [homeassistant.components.mysensors] Adding new devices: [<Entity DevNode 179 98: None>]
DEBUG (MainThread) [homeassistant.components.mysensors.device] Entity update: DevNode 179 98: value_type 47, value = #
DEBUG (MainThread) [mysensors.gateway_mqtt] Receiving 179;98;2;0;47;
DEBUG (MainThread) [mysensors.gateway_mqtt] Publishing 179;98;1;0;47;#

Serial output on the node:

8812 TSF:MSG:READ,0-0-179,s=98,c=1,t=47,pt=0,l=1,sg=0:#
Received a message: #

The notify.mysensors service appeared right after presenting the new V_TEXT/S_INFO child. Sending custom messages from there works aswell.

Serial output:

413829 TSF:MSG:READ,0-0-179,s=98,c=1,t=47,pt=0,l=11,sg=0:TestMessage
Received a message: TestMessage

@Puneit-Thukral The MySensors integration in Home Assistant has no unit associated with V_PRESSURE, as it can have a variety of units (pascal, bar, mercury, psi,...). You either need to specify a custom unit_of_measurement in HA, like so:

sensor.pir_bme_sensor_143_4:
  friendly_name: Air Pressure
  unit_of_measurement: hPa

https://www.home-assistant.io/docs/configuration/customizing-devices/

... or present a custom unit in MySensors with V_UNIT_PREFIX, like so:

#define CHILD_ID_PRESSURE 4 // <- use the same ID as for the sensor
MyMessage msgPrefix(CHILD_ID_PRESSURE, V_UNIT_PREFIX);
void setup() {
  send(msgPrefix.set("hPa"));
}

https://www.home-assistant.io/integrations/sensor.mysensors/#custom-unit-of-measurement

Alright, I got the ESP MQTT GW working for the better part of the last two days, handling an average total of 48 messages (36 sending, 12 requesting) per minute from two nodes and all seems good so far. As you can see in the image below, I'm using the RX (GPIO 3) / TX (GPIO 1) pins for CE and CS and I have MY_DISABLED_SERIAL defined, which means that I can't see the serial output of the GW. But looking at the corresponding MQTT topics and the serial output of the nodes, I confirmed that every in- and outgoing message was handled correctly.

I've tried a bunch of other pin assignments, of which I've included two in the image. With the one shown in the middle, I saw tons of NACKs on the serial output of the NRF24 node. I think this is because D3 (GPIO 0) and D4 (GPIO 2) are used to determine the boot mode of the ESP and are pulled high to VCC. Using them for the IRQ pins isn't going to work either - at least not without external circuitry - because the RFM69 will pull the line down and the NRF24 will pull it up, preventing the ESP from booting / flashing.

If D3 and D4 can't be used, there are only seven easily accessible GPIOs left (not counting RX/TX here) for a total of eight IO pins on both radios (2x IRQ, 3 for SPI, CE, CS and NSS). I decided to leave the IRQ pin of the NRF24 radio unconnected and ended up with a pin assignment as shown on the right. In this setup, all messages received an acknowledgement, even though not all sent messages appeared in the GW serial output, nor in the corresponding MQTT topic.

So yes the dualRF GW is working on a NodeMCU (ESP-12E), if you can do without serial output, don't care about traffic indicator LEDs, inclusion mode and such. Since many of the pins have two, three or more functions depending on the ESPs state, I don't think I would recommend it as a dualRF gateway, unless someone who has more patience steps in to figure out if and how all GPIOs can be made accessible. Better use a different MCU for this.

Let me know if you need a specific log or want me to test something with it. I'd be happy to help. Otherwise I'd like to free my breadboards up for other projects.

GW sketch:

#include <Arduino.h>

// #define MY_DEBUG
#define MY_DISABLED_SERIAL
#define MY_BAUD_RATE 115200

#define SKETCH_NAME "ESP dualRF Gateway"
#define SKETCH_VERSION "1.0"

// WiFI config
#define MY_GATEWAY_ESP8266
#define MY_HOSTNAME "MySensors-ESP-GW"
#define MY_WIFI_SSID "ssid"
#define MY_WIFI_PASSWORD "pwd"

// MQTT config
#define MY_GATEWAY_MQTT_CLIENT
#define MY_MQTT_CLIENT_ID "my-gw"
#define MY_MQTT_PUBLISH_TOPIC_PREFIX "mytest-out"
#define MY_MQTT_SUBSCRIBE_TOPIC_PREFIX "mytest-in"

#define MY_MQTT_USER "user"
#define MY_MQTT_PASSWORD "pwd"

#define MY_CONTROLLER_IP_ADDRESS 192, 168, 178, 220
#define MY_PORT 1883

// NRF config
#define MY_RADIO_RF24
#define MY_RF24_CHANNEL 83
#define MY_RF24_PA_LEVEL RF24_PA_HIGH
#define MY_RF24_USE_INTERRUPTS
#define MY_RF24_IRQ_PIN D1
#define MY_RF24_CE_PIN D9
#define MY_RF24_CS_PIN D10

// RFM config
#define MY_RADIO_RFM69
#define MY_RFM69_NEW_DRIVER
#define MY_RFM69_NETWORKID 69
#define MY_RFM69_FREQUENCY RFM69_868MHZ
#define MY_IS_RFM69HW
#define MY_RFM69_IRQ_PIN D2
#define MY_RFM69_IRQ_NUM MY_RFM69_IRQ_PIN
#define MY_RFM69_CS_PIN D8

#include <ESP8266WiFi.h>
#include <ArduinoOTA.h>
#include <MySensors.h>

void presentation()
{
	sendSketchInfo(SKETCH_NAME, SKETCH_VERSION);
}

void setup()
{
	ArduinoOTA.onStart([]() {
		Serial.println("ArduinoOTA start");
	});
	ArduinoOTA.onEnd([]() {
		Serial.println("\nArduinoOTA end");
	});
	ArduinoOTA.onProgress([](unsigned int progress, unsigned int total) {
		Serial.printf("OTA Progress: %u%%\r", (progress / (total / 100)));
	});
	ArduinoOTA.onError([](ota_error_t error) {
		Serial.printf("Error[%u]: ", error);
		if (error == OTA_AUTH_ERROR)
		{
			Serial.println("Auth Failed");
		}
		else if (error == OTA_BEGIN_ERROR)
		{
			Serial.println("Begin Failed");
		}
		else if (error == OTA_CONNECT_ERROR)
		{
			Serial.println("Connect Failed");
		}
		else if (error == OTA_RECEIVE_ERROR)
		{
			Serial.println("Receive Failed");
		}
		else if (error == OTA_END_ERROR)
		{
			Serial.println("End Failed");
		}
	});
	ArduinoOTA.begin();
}

void loop()
{
	ArduinoOTA.handle();
}

Do you have a spare breadboard at hand? If not, a bunch of Dupont wires should be fine aswell. Build a minimal circuit and go to your garden. Try to connect to the network with different NRF24 modules and see which one works best. Ideally, you would also bring a notebook to read the serial output and play with #define MY_RF24_PA_LEVEL and #define MY_RF24_DATARATE.

It's hard to tell how well a wireless connection will perform in a specific location, there are just way to many factors - shape of the landscape, obstacles, WIFI networks and other signals, the weather, humidity,... . So it's best if you test this personally. I highly doubt though that you will be able to get 1100m range out of those PA LNA modules. I used them earlier and they didn't reach much further than regular NRF24 modules with PCB antenna and no amplifiers. I've switched to cdebyte E01-ML01DP5 for gateway and repeaters.

Generally, I think you want to have a sender with a high power amplification (PA), if you want to transmit over a large distance. A high receive sensitivity on the target (gateway / repeater) is of no use, if the transmitted signal is so weak, that it can't even remotely reach it. It would get lost in noise.

Sure, getting ~90m range out of NRF24 is possible, but RFM69 / 95 is better suited for this.

Welcome @Asaf-Frige

Please follow the integration guide for MySensors in the Home Assistant docs.

It includes all the information you need to connect a serial gateway to Home Assistant, including a sample configuration and sketch. If you have any open questions afterwards, feel free to ask.

Well, a much neater solution than what I'm using on my nodes was developed recently in this thread (relevant post with code here), which makes use of MySensors' internal indication system:

void indication(indication_t ind)
{
  switch (ind)
  {
    case INDICATION_TX:
      txOK++;
      break;
    case INDICATION_ERR_TX:
      txERR++;
      break;
  }
}

void loop()
{
  static unsigned long last_send = 0;
  if (millis() - last_send > REPORT_INTERVAL) {
    send(txOKmsg.set(txOK));
    send(txERRmsg.set(txERR));
    last_send=millis();
  }
}

It has the benefit, that it also works on repeaters and the GW, because MySensors handles everything under the hood (besides the number incrementation and sending of the values, of course).

I didn't feel like updating all my working nodes with this yet, so I'm mostly still doing it manually. I also prefer to reset the error counter to zero when the value has been reported. I feel it's easier to keep track, when and how many errors appeared that way. And it's nicer to visualize in a graph than an incremental value.

On simple nodes, sending only one or two values, I keep it quite basic:

uint8_t txErrors;

void loop() 
{
	// Increase counter, if send() returns false
	if (!send(msg.set(value))
	{
		++txErrors;
	}
	
	// Send msgTxErrors only if there have been errors to save battery
	if (txErrors) 
	{
		// Only reset counter if error count has been sent successfully
		if (!send(msgTxErrors.set(txErrors)) 
		{
			++txErrors;
		} 
		else 
		{
			txErrors = 0;
		}
	}
}

For larger nodes, like the weather station, I have a wrapper around send() to keep the code tidy which basically looks like this:

uint8_t txErrors;

struct Measurement
{
	Measurement(const char *n, float t, uint8_t d, bool c) : NAME(n), THRESHOLD(t), DECIMALS(d), SEND_ALWAYS(c){};
	const char *NAME;
	float value = 0;
	float lastValue = -1;
	uint8_t silentCount = 0;
	const float THRESHOLD;
	const uint8_t DECIMALS;
	const bool SEND_ALWAYS;
};

// For each child / sensor 
Measurement Lux{"Illuminance", LUX_THOLD, LUX_DECIMALS, LUX_SEND_ALWAYS};

void transmit(const MyMessage &msg, Measurement &m)
{
	if (...) // Check if threshold crossed, etc ...
	{
		if (!send(msg.set(m.value, m.DECIMALS)))
		{
			++txErrors;
		}
	}
}
	
void loop() 
{
	// For each child / sensor 
	transmit(msgLux, Lux);

	if (send(msgTxErrors.set(txErrors)) 
	{
		txErrors = 0;
	} 
	else 
	{
		++txErrors;
	}
}

If you're using repeaters and are worried that they may loose the node's messages on the way, you could request an echo from the target (GW usually) to make really sure that the message arrived:

void loop() 
{
	send(msg.set(value),true);
}
void receive (const MyMessage &msg) 
{
	if (msg.isEcho()) 
	{
		// Msg (and valid echo) arrived
	}
}

SI7021.h isn't part of of the main MySensors repo anymore since 2.0 was introduced. You can download it from the MySensors examples repo.

RunningAverage.h is available here or directly from the Arduino library manager.

And finally, sha204_lib_return_codes.h and sha204_library.h can be obtained from the Security Personalizer sketch. If you're going to copy and paste those files into the Arduino project folder, you may need to replace the <...> brackets around the included file with "..." (e.g. #include "sha204_library.h"), or else the IDE might not find them.

After solving the dependencies, I got it compiling on both Arduino IDE...

Sketch uses 17586 bytes (57%) of program storage space. Maximum is 30720 bytes.
Global variables use 749 bytes (36%) of dynamic memory, leaving 1299 bytes for local variables. Maximum is 2048 bytes.

... and PlatformIO

RAM:   [====      ]  36.4% (used 746 bytes from 2048 bytes)
Flash: [======    ]  57.1% (used 17536 bytes from 30720 bytes)
========================= [SUCCESS] Took 1.64 seconds =========================

I don't know why there are so many missing dependencies in in the Sensebender Micro example. Considering that it has been updated three years ago for the last time, it might be time for a review? (Maybe it's also time for me to finally get a GitHub account... ) Adding hints on how and where to find the missing dependencies I've listed above in the readme file might be sufficient - it's compiling, but I can't tell if it'll run as expected.

Would be great if any of you could report back if you got it working on the actual hardware.

@MisterMel said in !TSM:FPAR:NO REPLY:

I also have an Arduino Nano hooked up to another NRF24 of the same type, but it has !TSM:FPAR:NO REPLY messages in the Serial console

Are you powering the NRF24 PA-LNA module directly from the 3V3 pin of the Nano? The Nano doesn't have a dedicated voltage regulator for 3.3V on board. 3.3V are provided through an LDO integrated into the USB-UART controller. If it's a genuine FTDI, it can provide up to 50 mA, but if your Nano is a Chinese clone, it's more likely that they are using a CH340 or something like that. This chip may be able to deliver 25 mA or so and might not be able to regulate larger loads properly, which could cause a lot of noise on the 3.3V line - something that NRF24 transceivers don't like at all. Besides that, those black PA-LNA modules may draw up to 150 mA during transmission, which would be far out of spec on higher PA levels and may permanently damage the USB-UART controller.

That could be the or a reason why your Nano node doesn't seem to be able to reach the GW. Try hooking up a regulated 3.3V power source to the radio in this case.

@DenisJ Do NOT leave out decoupling capacitors for the MCU, because you may run into stability issues without them. Ideally, you'd place one 100 nF MLCC as close as possible to every VCC pin. But in my experience it's fine to use one MLCC for the two VCC pins that are next to each other on the ATmega328P-AU and one MLCC for the AVCC pin.

It's also advised to connect AREF to ground through a 100 nF MLCC to make it more immune to noise if you are using the internal reference to read the battery voltage. Otherwise, if you don't use the ADC at all, just leave it unconnected.

@DenisJ said in New simply node sensor project - please some advise:

p.s. in the mean time I found this one that have only 7 mΩ MSR
Do you think it's ok please ?

Pay closer attention to the specs of the parts you pick. This tantalum cap is rated for 1.8V only. It'll fail before you get your first measurements from this node.

If you choose to stick with tantalum for their compact size, opt for one that's rated for 10V, or maybe 6.3V. If you run them at 3V, they should be roughly in their "sweet spot" regarding DC leakage.

Speaking of leakage current: Larger capacitors should be able to help stabilize the voltage further when the RFM69 is transmitting, but the leakage current increases with larger capacity. A high leakage current can noticably cut down on the total battery lifetime, as a low current consumption during sleep is most important for long lasting batteries in devices like this.

Although the RFM69 will likely draw considerable more than your multimeter shows (I guess it's too slow to show the "real" peak current; IIRC datasheet states 45 mA peak for non-H RFM69 and up to 130 mA for the H version), I think about 470 µF should be a good compromise here.

If you don't mind the physically larger size, consider using an electrolytic capacitor instead. They are safer to use and usually achieve lower DC leakage currents. I can personally recommend the Nichicon UMA / UMR series. You may use the electrolytic (or tantalum) capacitor in conjunction with a lower capacity (~10 µA) MLCC.

You could also get a few large capacity MLCCs instead of the tantalum, as @skywatch suggested. With MLCCs you typically don't have to worry about DC leakage, but note that their operating capacity reduces drastically, the closer the applied voltage is to their rated voltage. For example, a 100 µF MLCC rated for 6.3V may only have 60µF at 3V or 30µF at 6V. But you can always add multiple in parallel.

Those are all viable options.

@markjgabb said in fails to wake with 2 interupts:

#define DIGITAL_INPUT_SENSOR 2
#define DOOR_PIN  3
[...]
void loop()
{
    sleep(DIGITAL_INPUT_SENSOR,CHANGE,DOOR_PIN,CHANGE,SLEEP_TIME);
}

Use the function digitalPinToInterrupt(). It translates the pin number (2, 3) to the corresponding interrupt vector (0, 1).

sleep(digitalPinToInterrupt(DIGITAL_INPUT_SENSOR), CHANGE,
      digitalPinToInterrupt(DOOR_PIN), CHANGE,
      SLEEP_TIME);

The cTDP is generally only provided for APUs (CPU + GPU on a single chip). It allows OEMs to easily limit the power draw (mainly the all core boost clock) to match the CPU to their thermal design requirements. That's why two equally equipped notebooks can have vastly different performance results. It's a pity that OEMs almost never advertise their cTDP setting.

The desktop CPU market is a little different. Thermal design isn't that critical, CPUs are also sold directly to end users, etc. While it may depend on the mainboard manufacturer to enable the cTDP setting in their UEFI, it is generally possible to adjust it on desktop Ryzens as well. Many do that to find their efficiency sweet spot. I guess nothing could stop you from setting a 5600X's cTDP to 15W. That's what I did with my Athlon as well, albeit only from 25W to 15W. Besides the cTDP, there are other ways to increase efficiency: Lowering the PPT threshold, setting a negative vCore offset, etc. But that whole topic is too complex to explain or discuss here. You may search on PC hardware websites like AnandTech, Tom's Hardware, GamersNexus, Guru3D and such for more details if you're interested.

Here's a 5600X review by Tom's Hardware. They suggest that it draws 13W in idle at stock settings, which are 20% of the nominal 65W TDP. Other reviewers may get different results, due to hundreds of different combinations of configurations, hardware choice and measurement methods. I assume that you can reduce those 13W even further with some adjustments, but don't take my word on that. Unfortunately, I don't own a Ryzen right now to test that myself.

That being said, I don't think you can realistically underclock a desktop CPU to match the power draw of their mobile pendants. So the mobile CPU may always be more economical.

Maybe the embedded lineup of CPUs like the Intel Xeon D or AMD V / Epic Embedded may suit you? They are generally more targeted towards industrial use and have far more connectivity options than those NUC-style mini PCs or notebooks. Commercial NAS vendors like Synology use those. Unfortunately, at first glance, it looks like both Intel and AMD solutions seem rather outdated at the moment.

Hello @NONO87, looks like your node isn't able to establish a connection with the gateway, so it's stuck in the transport initialization sequence and never enters the loop() or even setup() where the OLED is initialized. Here's the boot sequence diagram for reference.

You may try to add #define MY_TRANSPORT_WAIT_READY_MS 1 (or anything > 0) to timeout transport initialization early and see if the OLED is still working.

If it does, you next goal would be to find out why this node doesn't connect to the gateway. The node is either unable to receive messages from the gateway or the messages it sends don't reach the gateway.

Is the serial module correctly wired? Configuration is fine on both devices? Is the gateway working and does it receive find parent request from this node?

You may want to use the Log Parser to make the serial output "human readable".

@NeverDie said in Best PC platform for running Esxi/Docker at home?:

At any rate, it looks as though the idle wattage for just the Ryzen 5 5600X cpu is around 26 watts:

See what I mean with "other reviewers may get different results"? ThinkComputers says 26W idle. Tom's Hardware says 13W. AnandTech says 11W. TPU says 50W (whole system). Who is right? It's unfortunate that there is no standard testing procedure every reviewer adheres to.

Part of the different results may be due to mainboard selection. Some (I don't know how many and if they are rare or the majority) AM4 mainboards seem to be rather power hungry. Especially those with an X570 chipset. Some may add another 10 to 20W to the total power consumption, even if you use the same CPU. See here for example.

26w is manageable with a quiet fan.

Oh yeah, absolutely! Even under load. My 80W Xeon sitting right next to me here is inaudible for most people unless they hold their ear close to the PC case.

Oh, and please note that I'm not trying to sell you the 5600X just because I used it as a comparison a few times. IMHO, all CPUs in that category are grossly overpowered for the average home server unless you know that you will need it sooner or later.

"Usually" is the correct term. You can request whatever you want using MQTT, but you need to handle the response manually inside the receive() function. This isn't an automatic internal process like the echo or ack response.

void receive(const MyMessage &message)
{
	if (message.getCommand() == C_REQ)
	{
		switch (message.getSensor())
		{
		case 10:
			// Send SSR 1 state
			break;
		case 11:
			// Send SSR 2 state
			break;
		case 20:
			// Send temperature sensor value
			break;
		case 40:
			// Send humidity sensor value
			break;
		default:
			break;
		}
	}
}

Note: It's best to not send a message from within receive() as it can cause all sorts of weird stuff, including recursive loops. Preferably, you'd set a flag and handle everything else in the main loop.

@mfalkvidd Domoticz is a full-blown home automation system, isn't it? Grafana is just a monitoring dashboard that pulls data from a time-series database (like InfluxDB) and generates fancy graphs. It can't automate and control things or send commands other than alarms (eg. if a value exceeds a threshold, or no new data came in since x minutes, send an email).

One of InfluxDBs limitations is that you can't use (or only some basic) math operations on db queries, which may limit what you can graph in Grafana. Also, changing data types of existing fields in measurements is also not possible, which is annoying, because Grafana treats values differently based on their data type. @sundberg84 can probably name more limitations. I'd love to switch to Carbon / Graphite for data collection and storage... if only it wouldn't take time to read up, setup and migrate all the data.

By the way - great idea to use the indication handler to log radio reliability! Definitely going to implement this on my gateways repeaters when I find the time.

@adds666 In receive(), note how you use relayPin:

  if (message.type == V_STATUS) {

    if (message.sensor == 7)  {
      if (message.getBool() == RELAY_ON) {
        digitalWrite(message.getSensor()-1+relayPin, RELAY_ON);

relayPin is an array (const uint8_t relayPin[] = {3, 7};). If you use it without specifying an index, like you do here, you get a pointer to the first element, not the value of an element.

Something like digitalWrite(relayPin[message.getSensor()-7], RELAY_ON) should work here. getSensor() returns 7, because you already checked for that two lines above. 7 - 7 = 0, which results in relayPin[0] and toggles the relay on pin 3.

Also, note that you load the current relay state from EEPROM positions 0 and 1 in setup():

for (uint8_t i = 0; i < MAX_RELAY; i++) {
  pinMode(relayPin[i], OUTPUT);
  //digitalWrite(relayPin, loadState(i)?RELAY_ON:RELAY_OFF);
  if (loadState(i) == RELAY_ON) {

But you save the state to byte 7 in receive():

saveState(message.sensor, message.getBool());

Hope this helps you out!

@skywatch I think you should be able to use isTransportReady() for this. It returns true if transport is ready and working, false if not.

#define MY_TRANSPORT_WAIT_READY_MS 1000 // Any value > 0
void loop()
{
    if (!isTransportReady())
    {
        // No uplink
    }
}

@NeverDie The guy with the swiss accent once said that you can coat the capacitive soil moisture sensors with a water resistant varnish or put it inside a waterproof shell.

https://www.youtube.com/watch?v=udmJyncDvw0
starting at ~7 mins.

@franz-unix Ha, Great minds think alike.

Well, it looks like you are still mixing up the meaning of sensor and sender in the code. If the controller sends a message to the sensor you have set up in the sketch above (20), while you are comparing against 0 in receive(), you will never detect that message. Compare against 20.

Remember how I advised to get rid of magic numbers and use constants instead? If you would add something like #define SENSOR_ID 20 and use that variable instead of 0 and 20, you might be able to avoid such confusions, because you give those arguments a meaningful name.

Let's try to explain it another way, so that you can adapt it to any situation in the future.

Sensor: In the context of a MySensors sketch, stop thinking of a sensor being a (physical) device. It is just a unique identifier for one of many different data points a device (MySensors calls this device a node) wants to share with others. Think of a sensor (or also often called child) as one of up to 255 wires going from one node to any other, whereby each wire represents a single type of data, like a temperature, a string, voltage level, a boolean value.

Sender: When a node sends a message, it includes a reference to itself - the node ID - as the sender, as well as a reference to the target node as the destination. Both sender and destination enable MySensors to route messages through the network, no matter if it is a direct A-to-B connection or if the message needs to be forwarded by multiple repeaters.

The MyMessage class is used to manage those messages. It stores all kinds of information neccessary to share data between nodes, send and request commands independently from the selected transport method (RF24, Sub-GHz, wired) and controller connection (Serial, MQTT, WiFi, Ethernet).

Imagine a simplified MyMessage instance as a collection of variables and a bunch of helper functions to make your life easier. When the controller (via the GW) sends the message to the node, as you described above, the message would look like this on the receiving node:

MyMessage msg 
{
	sender = 0;       // Node ID of the message's origin (the GW)
	destination = 7;  // Node ID of this device (I assumed this number!)
	sensor = 20;      // Child ID / data point that this message wants to update
	type = 3;         // S_BINARY == 3
	[...]
	getBool();        // Returns the payload as a boolean
	getSensor();      // Returns the value of sensor
	setSensor(n);     // Changes the value of sensor
	getDestination(); // Returns the value of destination
	[...]
}

So what do you have to do if you want to update the local variable RESET_SOFT on that node whenever it receives a new value? You have to test that the incoming message is of the expected type and that it concerns the right sensor. If you also want to make sure that only the controller or GW can cause an update of RESET_SOFT, you must validate that sender - in other words, the origin of this message - is valid as well.

I really hope this makes sense to you, as I'm running out of ideas how to explain what is going on behind the scenes.

Maybe a look at the Serial API introduction can also help you further.

@skywatch

When I add #define MY_NODE_ID to a gateway sketch what happens? Does it get ignored by the compiler or is it overruled by the MS library?

I assigned 99 to a GW and it seems to ignore it.

Serial output:

73 TSM:INIT:TSP OK
75 TSM:INIT:GW MODE
77 TSM:READY:ID=0,PAR=0,DIS=0

MQTT:

mytest-out/0/255/0/0/18-2.4.0-alpha
mytest-out/0/255/3/0/11-ESP dualRF Gateway
mytest-out/0/255/3/0/12-1.0

Also, I have currently 3 separate MQTT gateways configured in HA. All my nodes use static IDs and some IDs are used in multiple networks. As far as I can tell, messages in both directions are always directed to the right GW. At least I didn't notice anything go wrong so far.

@electrik Yeah, I ran into that issue, too. Not sure if that's the proper way to solve it, but I add a custom board directory to the build flags in platformio.ini ...

build_flags = 
	-I $PROJECT_DIR/boards/generic

... and copied the board variant files from .platformio/packages/framework-arduinonordicnrf5/variants/Generic/ to boards/generic/ in my project folder. Changes made in here aren't ignored or overwritten by global PIO definitions.

@evb The indication handler will not only be triggered by the error message, but also by (almost) all internal messages, like registration requests, node and sensor presentation, nonce, discovery responses, find parent requests, OTA firmware upgrades and others. Basically everything that uses the default transportRouteMessage() function.

It's up to you if this gives a wrong picture. If you want to know how reliable the uplink of node is, it's exactly what you would want to use, isn't it? If you, on the other hand, only care about your own messages, or perhaps even only a few of them, you would propably want to avoid the indication handler, as it may result in "false positives".

It's basically the opposite of the "track only a single MyMessage object" approach I was showing above.

@NeverDie Yes, LastPass vaults may have been secure as long as the master password couldn't be cracked, but it could have been worse, too. And who knows if (or when) they will be hacked again.

Maybe I'm too paranoid here, but I think data stored in someone else's public network is inherently insecure. You have to trust that a company protects some of your most valuable data, that they are not deceiving you with false promises and that their security engineers are more skilled than the black hats.

Remember the Ubiquiti hack recently? Attackers gained access to customers' cloud managed devices, by gaining root access to Ubiquiti's AWS cloud instances and S3 buckets via credentials stored in an IT employee's LastPass cloud account. What could happen if a key LastPass employee becomes a victim of a social engineering attack? Do they really have no master key or other way of decryption? With upwards of 25 million users storing their login credentials, LastPass is an attractive target for hackers.

Sure, a cloud-based password manager is still much safer than using the same password everywhere. The question is, where are your passwords more secure? In the hands of a company that can hire highly skilled security experts to protect the data of millions publicly, or in our own incompetent hands, stored locally, below the radar level of hackers and where nobody other than us has access to - well, unless we are directly targeted of course. Both ways have their own set of risks.

I personally prefer self-hosted, local or offline solutions over anything cloud- or account-coupled wherever that's an option.

Bitwarden has been mentioned a few times now. Apparently it can be self-hosted, too. Guess I should have a look at it sometime!

Yeah well. Some of those "holes" in password managers are conceptual. You can't display a password or copy it to a clipboard without exposing it. I guess we have to accept that no software is 100% secure and that nobody can ever guarantee such a thing. A lot has to come together before those flaws become a serious threat - and what's the alternative anyway?

Regarding browser extensions: While it's true what Brave is saying, I think it's the wrong conclusion to ditch extensions altogether. Websites themselves, even trustworthy ones, can be malicious. That is because most websites today load content from third parties like advertising or content distribution networks, for tracking purposes and to deliver targeted ads, regionally cached versions of the website or frequently used JS libraries like jQuery. If any of those third parties / CDNs gets compromised, attackers can inject harmful javascript into countless websites. The NYT, Yahoo and Spotify were rather famous victims* spreaders. Even Google's DoubleClick, one of the leading ad servers, has served malware before. (see malvertising on wikipedia).

I understand that there are website owners who rely on ads to fund their projects, and one can always make exceptions for them or compensate through different means (subscriptions, donations,..), but I would never use a browser without any sort of ad- or scriptblocker like uBlock origin or uMatrix these days. I prefer to know and decide on my own which resources and from where they are loaded. They also help to restrict cross site tracking.

Another nice side effect - which may confirm Brave's "3x faster" than Chrome claim - most websites load much faster. Take the NYT frontpage as an example:
No blocker: transferred 28MB in 356 requests, which took 4.43s to load; keeps loading in new images, videos and other resources from third parties every minute
With Blocker: 4.14MB in 58 requests, which took 1.76s; does not load anything from third parties afterwards

It's either that or disable javascript entirely in the browser, which will render many websites useless.

* I'm reluctant to call a website a victim in this case if they knowingly load content from third parties, accepting all the risks involved, but deny any responsibility in case they in turn cause harm to their customers / visitors.

The EU has developed a new tax payment portal for imports called Import One-Stop Shop (IOSS) for orders below 150 EUR together with the new regulations. Non-EU sellers who sell to EU citizens can use this to simplify the process and charge the correct VAT upfront in the store. The seller and the shipping company have to include an IOSS-related ID visible on the package for the customs office to check. If everything is documented correctly, the local post office should neither charge VAT nor a hefty service fee from you. That's the theory at least.

By now, many of the big trading platforms should have implemented IOSS. I know that AliExpress does for sure and most, if not all, sellers can make use of it - both of my two orders since July were VAT-included and Deutsche Post didn't charge me anything. I don't know how eBay handles that - I think they have no system in place, so that it is up to every single seller to use IOSS or let you deal with the customs. PCBway and JLCPCB do use IOSS, too. I'm not sure about LCSC yet.

But yeah, it is a silly regulation that can make small orders from overseas unreasonably pricey. Over here in Germany, we have some exceptions at least. Import tax (19%) is only due if it is worth 1 EUR or more, so it is only collected if the total merchandise value is 5,24 EUR or more. Deutsche Post / DHL charges another 6 EUR on top of that only if they have to collect the taxes from you. This leads to stupid situations where you can buy something for 5 EUR and have to pay only 5 EUR, but a purchase of 6 EUR can cost you 13,14 EUR including all the fees.

Edit: On the upside, let's appreciate how straightforward it finally got to buy stuff from overseas that is above the old import sales tax exemption limit (22 EUR usually), because it get's shipped directly to you without any delays. Until recently, the customs office held my parcels hostage and sent me a letter to let me know they have something for me to pick up. So I always had to drive 25 km with the printed out invoice - sometimes waiting up to half an hour in the queue - and open the package there just to pay a few euros.

@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.

I obviously can't speak for everyone, but I'm happy with the Ender 3 and have no need nor desire for another (filament) printer. The print area is large enough for my needs - custom electronics enclosures, spare parts / repairs, little mechanical tools and gadgets, etc. Print resolution and detail is fine, I generally have no noteworthy quality complaints aside from the occasional stringing (which is easy to remove with a lighter or hot air gun). Maintenance is as minimal as it gets: keep the v-groove wheels, belts and lead screw dust free, clean the glass bed. Talking about the glass plate: I fixate it with two regular metal binder clips to the original print surface. It sits tight in place and it's removable within seconds. I don't use hairspray, glue (I tried once - oh boy, what a mess) or anything else, I just rinse it with warm water and soap after a couple of prints. That's it. Keeping it in a good temperature window seems to be key for proper adhesion. I generally start the print with a bed temperature of 65°C for the first (few) layers and drop it to 50°C afterwards for PLA.

Now this doesn't mean that I want to persuade anyone to buy an Ender 3. I don't know if they are still recommended nowadays or if Creality may have started milking the cow. Honestly, I stopped following the 3D printer communities and news once I got my Ender 3 dialed in and achieved pleasing results. I really don't know which printer one should buy today.

But in the end, I don't think it matters much which printer you get. You can achieve good quality prints with most of them and in a lot of cases you'd have a hard time telling if something has been printed on a budget or high-end printer. It is much more important to learn how to use a (as in any) filament printer. How to use a slicer properly, learning what implications different temperatures, speeds and feed rates have, layer heights, how much infill is needed, which distances can be bridged, how steep overhangs and arches can be, retraction speed and distance, to-z-hop-or-not, finding the optimal extruder and bed temperatures for a specific filament, acceleration and jerk limits, cooling,... Knowing the basics of G-code is also very helpful to understand why a printer is doing something or even modify the print. Actually, it already starts with the design process in a CAD program - choosing a proper wall thickness, keeping the structure of the model in mind, avoiding supports if possible, etc.

No matter how expensive or pre-built and -tuned your printer is, those are things you need to get behind either way. The learning curve with a preconfigured, factory-calibrated printer might be less steep compared to a budget kit, because you are more likely to simply adopt the recommended settings from the manufacturer or other community members.

In this regard: if you're a tinkerer and like some challenges, you may as well build one yourself and have a great time! I'm looking forward to build a custom CNC (>1m² of surface area, for woodworking and occasional soft metal milling) soon - hopefully before the end of the year - rather because I'm interested in the build than having an urgent need for one.

@BearWithBeard said in PlatformIO instead of official Arduino IDE?:

It should also be possible to write a little script that automatically (re-)builds a separate Arduino IDE directory with everything in the src folder and let PIO execute it via extra_scripts whenever you build the program. This way you'd always keep a version for both environments.

Not sure if anyone has a use for it, but in order to get a little practice in Python I went ahead and wrote such a script, so I'll drop it here. Who knows, might come in handy at some point.

import configparser
import distutils.dir_util
import distutils.log
import os
import platform
import re
import shutil

Import("env")

logCopiedFilesToConsole: bool = False
optionMainFile: str = "custom_main_file"
optionArduinoDirName: str = "custom_arduino_dir"
defaultMainFile: str = "main.cpp"
arduinoFileType: str = ".ino"

# Read and parse platformio.ini
config = configparser.ConfigParser()
if not config.read(env.get("PROJECT_CONFIG")):
    print("Unable to read platformio.ini")

# Get paths and vars from SCons
projectDir: str = env.get("PROJECT_DIR")
projectSrcDir: str = env.get("PROJECTSRC_DIR")
envSection: str = "env:" + env.get("PIOENV")
projectName: str = os.path.basename(projectDir)


def sanitizeUserInput(input: str, isPathOrFile: bool = False) -> str:
    """ Sanitize user input strings. """
    input = input.strip("\"'")

    # Make sure the string doesn't violate file system rules
    if isPathOrFile:
        if platform.system() == "Windows":
            input = re.sub("[<>:/\\|?*]+|[.]$", "", input)
        else:  # Unix, macOS
            input = re.sub("[/]+", "", input)

    return input


def getOption(env: str, option: str) -> str:
    """ Retrieve a user-specified value from an environment option. """
    value = ""

    try:
        value = config.get(env, option)
    except configparser.NoOptionError:
        value = None  # To differentiate it from empty string
    except configparser.NoSectionError:
        print("Unable to find environment section %s" % env)

    return value


def getMainFile(defaultFile: str) -> str:
    """ Get the user-specified main file.
        If none is provided, default to defaultMainFile (main.cpp). """
    name = getOption(envSection, optionMainFile)

    if not name or name is None:
        name = defaultFile

    return sanitizeUserInput(name, True)


def getArduinoDirName(defaultName: str) -> str:
    """ Get the user-specified name for the Arduino IDE directory.
        If none is provided, default to project name. """
    name = getOption(envSection, optionArduinoDirName)

    if name is None:
        print("Using project name %s for the Arduino IDE directory.\n"
              "Specify %s in %s to provide a custom name. "
              % (defaultName, optionArduinoDirName, envSection))

    if not name or name is None:
        name = defaultName

    return sanitizeUserInput(name, True)


def copySourceDir(source: str, dest: str, logCopiedFiles: bool = False) -> None:
    """ Copy nox-existing or modified files and folders. """
    if logCopiedFiles:
        distutils.log.set_verbosity(distutils.log.DEBUG)

    distutils.dir_util.copy_tree(source, dest, update=1)


def renameFile(source: str, dest: str) -> None:
    """ Rename a single file. """
    if not os.path.isfile(source):
        print("%s does not exist. Trying to rename fallback %s to %s" %
              (os.path.basename(source), defaultMainFile, os.path.basename(dest)))
        source = os.path.join(arduinoDir, defaultMainFile)

    try:
        os.replace(source, dest)
    except OSError:
        print("Unable to rename %s to %s" %
              (os.path.basename(source), os.path.basename(dest)))


def getFilesInDir(directory: str) -> str:
    """ Get a list of strings of all files in a directory tree. """
    filelist = []

    for root, dirs, files in os.walk(directory):
        dir = root.replace(directory, '')
        for file in files:
            filelist.append(os.path.join(dir, file))

    return filelist


def cleanupArduinoDir() -> None:
    """ Compare contents of source and Arduino directory trees.
        Remove all files and directories in the Arduino directory which are 
        not present in the source directory."""
    srcDirContents = getFilesInDir(projectSrcDir)
    arduinoDirContents = getFilesInDir(arduinoDir)

    filesToRemove = set(arduinoDirContents) - set(srcDirContents)

    # Remove all files which aren't in the source dir
    for file in filesToRemove:
        if not file == mainArduinoFile:
            os.remove(os.path.join(arduinoDir, file.lstrip("/\\")))

    # Remove all empty folders
    for root, dirs, files in os.walk(arduinoDir, topdown=False):
        for dir in dirs:
            try:
                os.rmdir(os.path.join(root, dir))
            except OSError:
                pass  # Dir not empty, we want to keep it


arduinoDirName: str = getArduinoDirName(projectName)
arduinoDir: str = os.path.join(projectDir, arduinoDirName)
mainFile = getMainFile(defaultMainFile)
mainArduinoFile: str = arduinoDirName + arduinoFileType

copySourceDir(projectSrcDir, arduinoDir, logCopiedFilesToConsole)
renameFile(os.path.join(arduinoDir, mainFile),
           os.path.join(arduinoDir, mainArduinoFile))
cleanupArduinoDir()

It creates a discrete directory for the Arduino IDE in the root of the PIO project and copies all files and folders inside the source directory over. It only copies files which have been modified or aren't yet in the Arduino IDE directory. The main code file will be renamed accordingly and the directory cleaned up afterwards.

Since all required paths and variables are retrieved from PIOs construction environment, it still works for customized project structures, for example if src_dir has been moved. This also means that it doesn't matter where you put the script. Keep a copy of the script with every project or provide a single one globally - just make sure to provide a valid path to it with the extra_scripts option and PIO will execute it whenever you create a new build.

Add the following line(s) to your platformio.ini:

[env:yourenv]
...
custom_main_file = start.c
custom_arduino_dir = ArduinoProject
extra_scripts = post:build_arduino_dir.py

custom_main_file is optional and can be specified, if main.cpp is renamed to something else (here: start.c). This file will be renamed to the main .ino file.

custom_arduino_dir is optional as well. You can provide a custom name for the new directory and the main .ino file. If none is provided, it defaults to the name of the PIO project directory.

For example, path/MyProject/src/main.cpp will result in path/MyProject/MyProject/MyProject.ino per default. With "ArduinoProject" specified for custom_arduino_dir, it'll create path/MyProject/ArduinoProject/ArduinoProject.ino.

Tested on Win 10 and Arch Linux.

@Sebex The Si7021 guide mentions that you have to install the Arduino VCC library (link to GitHub) if you want to use this feature:

Example

This example uses the Si7021 library, which is included in the MySensors external examples. If you choose to report battery level to the gateway (by defining REPORT_BATTERY_LEVEL at the top of the sketch) the Vcc library is also required. Please install the librarie(s) and restart the Arduino IDE before trying to compile.

It might be a good idea to add a link to the library in the article itself, since it doesn't make clear which library is required for this.

I own a regular household ultrasonic cleaner. 50W, 46 kHz, without manual heating control. I've tried cleaning a PCB once with distilled water, but it wasn't very promising. Not all of the flux came off and the board was still sticky after blowing it dry with compressed air. Then again, I'm using rather tacky homemade flux made of rosin, isopropyl and a bit of glycerin.

Anyway, I wouldn't want to use large amounts of alcohol or similar volatile solvents in a semi-open device, that also heats up when in use. That just sounds like a fire hazard waiting to happen, since it evaporates rather quickly and the flash point is below room temperature (e.g. isopropyl is somewhere between 10 - 15°C). With enough vapours in the air, a spark (static discharge?) near the cleaner might be sufficient for a neat little explosion, in a worst case scenario. Industrial ultrasonic cleaners might have some kind of safety features to reduce the risk of explosions and / or fires, I guess. I'd rather try a less dangerous, commercial ultrasonic cleaning solution for electronics, but I have no suggestions for that.

Since I'm not dealing with large amounts of PCBs that need to be cleaned, I stick with isopropyl and a tooth brush, like skywatch.

Hello! Hope you're all having a good day.

I'm trying to use a NRF24L01+ module on a "bare" ATmega328P-PU, but I fail to initialize the radio, no matter what I do.

The ATmega328P is basically a "virgin" from a reputable distributor.

I placed it on a breadboard, added 0.1µF ceramic caps to both power pin pairs and a 10kΩ resistor between pin 1 and VCC, to pull reset high.

The NRF24L01+ has its own electrolytic cap right next to it.

The whole circuit is powered with 3.3V.

Programming is done via PlatformIO in VS Studio Code on a Mac and using a USBasp. MySensors library is v2.3.1

Here's a quick Fritzing drawing of the setup:

This is the sketch I use:

#include <Arduino.h>

#define MY_DEBUG
#define MY_BAUD_RATE 19200

#define MY_RADIO_RF24
#define MY_RF24_PA_LEVEL RF24_PA_LOW

#define CHILD_ID 5
#define LED_PIN 8

#define SKETCH_NAME "Test Sensor"
#define SKETCH_MAJOR_VER "1"
#define SKETCH_MINOR_VER "0"

#include <MySensors.h>

MyMessage msg(CHILD_ID, V_TRIPPED);

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

void presentation()
{
  sendSketchInfo(SKETCH_NAME, SKETCH_MAJOR_VER "." SKETCH_MINOR_VER);
  present(CHILD_ID, S_DOOR);
}

void loop()
{
  digitalWrite(LED_PIN, HIGH);
  send(msg.set(HIGH));
  wait(1000);
  digitalWrite(LED_PIN, LOW);
  send(msg.set(LOW));
  wait(1000);
}

After building and uploading it via pio run -t program, the debug log consists of an endless loop of failed radio inits:

(Also, the LED on pin 8 does not blink. I guess that's because the program never leaves the setup() if the radio cannot be initialized.)

 __  __       ____
|  \/  |_   _/ ___|  ___ _ __  ___  ___  _ __ ___
| |\/| | | | \___ \ / _ \ `_ \/ __|/ _ \| `__/ __|
| |  | | |_| |___| |  __/ | | \__ \  _  | |  \__ \
|_|  |_|\__, |____/ \___|_| |_|___/\___/|_|  |___/
        |___/                      2.3.1

208 MCO:BGN:INIT NODE,CP=RNNNA---,REL=255,VER=2.3.1
331 TSM:INIT
344 TSF:WUR:MS=0
366 !TSM:INIT:TSP FAIL
391 TSM:FAIL:CNT=1
411 TSM:FAIL:DIS
430 TSF:TDI:TSL
10448 TSM:FAIL:RE-INIT
10471 TSM:INIT
10493 !TSM:INIT:TSP FAIL
10520 TSM:FAIL:CNT=2
10541 TSM:FAIL:DIS
10561 TSF:TDI:TSL
20584 TSM:FAIL:RE-INIT
20606 TSM:INIT
20629 !TSM:INIT:TSP FAIL
20656 TSM:FAIL:CNT=3
20676 TSM:FAIL:DIS
20697 TSF:TDI:TSL
...

Things I have tried to solve this:

• Checked the connection of all the wires
  • Checked if there is continuity between every connection, from pin to pin
  • Measured voltage on all VCC and GND pins
  • Swapped out every wire
  • I even swapped out the breadboard
• I swapped out the radio module with two others (all without "blobs"), one of which I took straight out of a project (not using MySensors) that was known working and running minutes prior to this (and still does)
• I tried using various different power sources
  • The USBasp itself
  • A small "breadboard PSU" via USB
  • A wall wart with adjustable output, set to 3.3V
  • All of which were able to provide sufficient power for various other projects featuring the NRF24L01+ previously
• Used a whole bunch of different electrolytic capacitors between 4.7 and 220µF for the radio
• Changed the low fuse byte of the ATmega328p from 0x62 to 0xE2, which sets the CKDIV8 bit to be unprogrammed, so that the MCU runs on 8MHz instead of 1MHz
• Used various baud rates from 9600 to 115200 (19200 works best for me)
• Uploaded a minimal sketch that drives all the SPI pins (9-13) high / low and measured if they all output stable 3.3V / 0V, which they did
• Explicitly defined CE and CS pins as 9 and 10 in the sketch

And probably a whole bunch of other things, too. But nothing helped to successfully init the radio. It doesn't seem to be a connection issue, nor a power issue.

What is interessting though:

• If I use the exact same hardware setup but use a different library to communicate over the radio (TMRh20 RF24 lib) instead of MySensors, I can send messages to a second radio just fine.
• If I use the exact same sketch and setup, but on a Arduino Duemillanove, Nano or Pro Mini instead of the bare ATmega328P, the radio initializes right away.

Every part on its own seems to be working perfectly fine. Only when the ATmega328P and the MySensors library come together, it fails.

Any idea what's happening here?

Well, I jump between operating systems a lot, so I'm naturally interested in software than runs on all platforms. In terms of IDEs, that means using Visual Studio Code, even though it's an Electron app, because with it I can do everything I need, from simple text editing, to-do lists, to programming in various languages and with different frameworks. (I can literally feel the eye-roll of some folks for using a product which is both based on Electron and from Microsoft, but oh well ¯\(ツ)/¯. I may have to look into the Jetbrains products.)

Ensuing from this, why would I want to switch to the Arduino Pro IDE? Like most people (I think anyways) who weren't happy with the Arduino IDE, I migrated away, because other IDEs provided tools that the Arduino IDE didn't. And as of yet I don't see the new Pro IDE brining anything new to the table, so I think it will be difficult for them to win those users back.

I've downloaded the Pro IDE earlier this year - I think it was still Alpha 0.0.5 - and at first glance it had a lot of similarities with VS Code. It has the same look and feel, many UI concepts are identical. The config is now a (UI-configurable) JSON file, just like in VS Code. Among others, it uses the same CTRL + P and CTRL + SHIFT + P shortcuts to search for files and commands. Then again, even such basic things like code formatting or even syntax highlighting didn't work at all. And almost a year after its introduction, it's still in an (early?) alpha stage - so I don't know what we should realistically expect from it. I mean, it's definitely a step in the right direction, but they have a looong way to go to be able to compete with other IDEs.

When I first heard about the Pro IDE, I was curious if they would manage to implement an open hardware debugger for AVRs, because as of yet, this is AFAIK still only possible with proprietary Atmel / Microchip hard- and software. But I doubt that this is going to happen.

@ZwaZo

The example compiles for me in IDE 1.8.12

Sketch uses 14338 bytes (46%) of program storage space. Maximum is 30720 bytes.
Global variables use 503 bytes (24%) of dynamic memory, leaving 1545 bytes for local variables. Maximum is 2048 bytes.

Please verify that you are using the latest version of the MySensors library (2.3.2).

@NeverDie Well, I have safety concerns because of the relatively large amounts of liquid that are needed. IIRC, my ultrasonic cleaner requires to be at least half-full, which is a little more than 250ml, or one bottle of isopropanol. And after the 5 minute bath, what do you do with it? Dumping it seems wasteful, transfering it back into a bottle is inconvenient and again, potentially dangerous, depending on the environment. Leaving it in the cleaner for the next use? Nah, I'm not risking it. It might be fine 99% of the time you use it, but you also wouldn't make a narrow cut on a table saw without a push stick, would you?

What I think could be a good compromise, is filling the ultrasonic cleaner with water and place the PCB in a zip bag filled with enough solvent to submerge it, squeezing the air out and then place that bag in the cleaner. Like sous-vide cooking. It provides isolation and the solvent, of which is much less required, can be handled separately in a save location.

Oh, and regarding isopropanol vs ethanol: Here in Germany, I can get a liter of 99% isopropanol for about 3 EUR. That's not really much more than 96% denatured ethanol. With ethanol however, I found that it tends to leave some sort of film on the PCB, which has a kind of dull and blochy appearance. Not the uniform, shiny finish you would like to see after cleaning. Also, while making my own flux, I found that pure rosin dissolved better in isopropanol than in ethanol. And while some of the rosin in ethanol started to crystallize after a few weeks, the isopropanol-based flux is still completely liquid after over a year.

Hi @JCH

Have a look at the code of your pool node. You are hiding all your temperature measurement and LCD display logic inside the if (message.type==V_TEMP) condition. So if no message is received, this node will do nothing but continue to listen.

Besides that - please prove me wrong - I think it is a bad idea to process so much code inside receive() and especially to send out messages from there. This can cause all sorts of weird stuff including recursive loops. You also shouldn't use sleep() on nodes which are supposed to listen to incoming messages. Use the non-blocking wait() instead if you have to.

I would suggest to move all the code which is related to the temperature sensor and the LCD display into the main loop(), fetch the temperature, send it and update the LCD on fixed intervals.

In your receive() function, listen for the incoming message only. If you receive a new temperature value, store it in a global variable (for simplicity) like roofTemp which you can access in the loop(). That's all you need to do here.

You could also set a boolean flag like receivedMessage to true in receive() when a new messages comes in if you want to update the LCD immidiately. But in general, keep it short.

Also i wasnt getting alot of the messages

Could be caused by putting the node to sleep aswell. The MCU will propably need less than a second to process all the instructions in your sketch. If you put the node to sleep, it will be in a state where it can't process incoming messages most of the time.

@Ikes-72000 said in Compilation error nrf52_dk plateformio:

Scanning dependencies...
Dependency Graph
|-- <MySensors> 2.3.2
| |-- <Time> 1.6
| |-- <SPI> 1.0
| |-- <Wire> 1.0

Why does it list this Time library as a dependency? This shouldn't be here. Did you, at some point, include it in lib_deps? Because your current issue seems to be related to this lib, not MySensors. Without it, it should compile just fine.

Processing nrf52_dk (platform: nordicnrf52; board: nrf52_dk; framework: arduino)
-----------------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/nordicnrf52/nrf52_dk.html
PLATFORM: Nordic nRF52 4.4.0 > Nordic nRF52-DK
HARDWARE: NRF52832 64MHz, 64KB RAM, 512KB Flash
DEBUG: Current (jlink) On-board (cmsis-dap, jlink) External (blackmagic, stlink)
PACKAGES:
 - framework-arduinonordicnrf5 1.600.190830 (6.0)
 - tool-sreccat 1.164.0 (1.64)
 - toolchain-gccarmnoneeabi 1.70201.0 (7.2.1)
LDF: Library Dependency Finder -> http://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 6 compatible libraries
Scanning dependencies...
Dependency Graph
|-- <MySensors> 2.3.2
|   |-- <Wire> 1.0
|   |-- <SPI> 1.0
Building in release mode
Checking size .pio\build\nrf52_dk\firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [          ]   2.1% (used 1352 bytes from 65536 bytes)
Flash: [          ]   3.8% (used 19784 bytes from 524288 bytes)
============================== [SUCCESS] Took 1.51 seconds ==============================

Try pio lib uninstall Time or remove it manually from the libdeps folder and rebuild the sketch.

@Fear-na-Boinne I don't know how your device / enclosure is built, but it's good practice to place environmental sensors as close to an opening in the enclosure and keep the dead volume around it as small as possible. Ideally, you'd put it in a separate chamber and move it as far away from other electronics and possible heat sources to minimize their influence to the measurements. If you're worried about dust, you could use thin cloth or something like that around the openings as a dust filter.

That being said, the BME/P sensors tend to report too high temperatures (just google for "BME temperature too high" or something like that - you'll find tons of topics), partly due to self-heating depending on how you use it, e.g. with oversampling enabled. IIRC, using forced mode, oversampling at 0 for pressure and 1 for temperature (and humidity) and filter turned off, is the prefered way for simple weather measurements with minimal current draw according to the datasheet.

If you have one of those 5V modules, the voltage regulator on board might give off some heat aswell.

The "easiest" fix would be to offset the temperature reading in software by a few degrees, if the reported temperature is off by the same value over the whole relevant temperature range (assuming 15 - 30°C for room temperature in your case).

I have no experience with it myself, but apparently, you can boot your RaspberryPi from an SSD if you want to. Considering how cheep they got recently, you might want to give this approach a try. You'll also need a SATA-to-USB3 adapter in this case.

@myrandow said in [Newbie] Little push in right direction (24nrf to MQTT Broker):

For the curious reader it added to the sketch ESP8266GatewayClient as mfalkvidd said #define MY_NODE_ID 42.

ESP8266GatewayClient is a sketch for a gateway. A gateway is unique in every MySensors network and has the ID 0. You can assign static IDs to any node but the gateway.

When @mfalkvidd suggested to add the static node ID, he meant your sensor node on the Arduino UNO, not the ESP-Gateway. Using static IDs allows your nodes to connect to each other and the gateway even if you have no controller set up (like Home Assistant, Domoticz, WebThings,..).

If you want the IDs to be assigned dynamically, you need a controller. Since you mentioned Home Assistant, I assume you intent to use it as a controller. Did you follow the integration guide and setup the configuration for MySensors and MQTT?

A MQTT broker alone can't assign IDs, nor can a Home Assistant instance which is not properly configured. Think of the MQTT broker as a mailman who delivers messages from the gateway to the controller and vice versa. If the controller doesn't know where its mailbox is (it doesn't subscribe to the MQTT topics), it can't read the messages and return an answer (the ID for the new sensor node), which means that the gateway will continue to send out the sensor node's request for an ID forever and ever.

@grumpazoid isEcho() returns a boolean which is either true or false and tells you if the incoming message is an echo (1) or not (0).

You can use it in the receive() function to filter out echos and print the content with any of the available getType functions provided by the MyMessage class, like getUInt() or getString(). The latter will convert any numeric type into a char array for you (if conversion isn't possible, it'll return NULL).

void receive(const MyMessage &message)
{
    if (message.isEcho()) {
        Serial.println(message.getString());
    }
}

@tssk I heard that people got rid of or at least reduced the coil whine by coating the windings of an audible inductor with non-conductive materials like epoxy resin or even hot glue to reduce the vibrations.

Of course, I woudn't mess with expensive PC hardware, but I guess there's not much to loose with a cheap boost module like this.

Hi Joost,

the Arduino Reference article you linked explains how to setup external interrupts, of which the Pro Mini has only two: INT0 on D2 and INT1 on D3. But there are many more interrupt vectors available - for a complete list see page 74 of the megaAVR datasheet - including pin change interrupts which enable you to use (almost) any pin as an interrupt.

Keep in mind though that pin change interrupts are lower priority than external interrupts and they will always call an interrupt on both the rising and falling edge. Since a button press usually changes the signal twice (closing and opening, plus possibly bouncing), you'll get two interrupts per click and and have to handle that in your ISR.

Here are two resources that should help you setting up pin change interrupts:

• https://thewanderingengineer.com/2014/08/11/arduino-pin-change-interrupts/
• https://playground.arduino.cc/Main/PinChangeInterrupt/

There are also dedicated libraries available which make pin change interrupts easier to use, but unfortunately I can't recommend any of these, as I have never used one.

Nick Gammons excellent interrupts introduction is also always worth reading:
http://www.gammon.com.au/interrupts

I'm currently experimenting with RFM69 radios. I've already built a well working multi-transport GW (NRF24 + RFM69) based on the current 2.4.0 dev branch - sketch and setup is posted here.

Now I'm evaluating the range / coverage of different RFM69 transceivers and antennas in and around the house, taking measurements using the RFM69_RFM95_ATC_SignalReport sketch with these defines:

#define MY_DEBUG
// #define MY_DEBUG_VERBOSE_RFM69

#define MY_SIGNAL_REPORT_ENABLED

// RFM69
#define MY_RADIO_RFM69
#define MY_RFM69_NEW_DRIVER   // Required by dualRF GW
#define MY_RFM69_NETWORKID 69

The multi-transport GW requires to use the new RFM69 driver, which has ATC enabled by default. As far as I understand, ATC is a technique to automatically adjust the TX power to match a specified TX signal strength (-80 dBm by default), which keeps the RF "polution" to a minimum and optimizes power consumption.

What I expect to see is a varying TX power depending on the signal quality / distance to the GW. A node right next to the GW should have a power level close to 0%. Across the house or outside, it should be much higher.

Here are some mean values collected over a period of half an hour each, using a non-amplified RFM69CW:

Location	Upl. Quality	TX RSSI	RX RSSI	Power (dBm)	Power (%)
Same Room as GW	-85	-92	-28	13	100
Floor below, two rooms across	-91	-94	-71	13	100
Garden (~30m)	-92	-94	-79	13	100

TX RSSI is always below the target of -80, so ATC is boosting the TX power to the highest possible level. Correct? But even when the node is close to the GW, the TX RSSI exeeds the target value. Bad antenna?

Now look what happens when I uncomment #define MY_DEBUG_VERBOSE_RFM69 on the node:

Location	Upl. Quality	TX RSSI	RX RSSI	Power (dBm)	Power (%)
Same Room as GW	-52	-57	-29	-18	0
Floor below, two rooms across	-78	-78	-63	-6	38
Garden (~30m)	-72	-78	-85	11	93

These results look far more reasonable! But defining MY_DEBUG_VERBOSE_RFM69 shouldn't make a difference, right? As soon as I remove it, I'm back to the results in the first table.

I've tried 2.3.2 and 2.4.0 on the node, they both behave the same. The RFM69 is connected to a 3V3 8 MHz Pro Mini. They are both powered with a regulated 3V3 source. MY_RFM69_ATC_MODE_DISABLED is not defined.

For the antennas I'm using straight solid core wires of 82mm length on both transceivers, directly soldered to the ANT pin. I don't think that this is the issue - the range and reliability of the connection is great: out of a total of 48436 messages, I got only got 21 NACKs (< 0,05%).

Am I missing something here? Is there a bug?

Hey, APL2017. In this example, pcMsg is the arbitrarily choosen name of a MyMessage class instance (apidocs), like

#define CHILD_ID 0
#define CHILD_ID_TEMP 42
MyMessage pcMsg(CHILD_ID, V_VAR1);
MyMessage temperatureMessage(CHILD_ID_TEMP, V_TEMP);

setDestination(destinationId) (apidocs) defines with which node you want to communicate. destinationId is the ID of the target node.

Accordingly, setSensor(sensorId) (apidocs) defines to which sensor ID on the target node this message should be mapped to.

set(floatValue, decimals) (apidocs) defines which float value should be sent with the given number of decimal places. Note that the set() function has a bunch of overloads for different value types - only floats accept the decimals parameter, for obvious reasons.

Summarized, send(pcMsg.setDestination(1).setSensor(101).set(temperature,1)) attempts to send a MyMessage of type V_VAR1 with the value of the temperature variable, trimmed to one decimal place, to sensor ID 101 on node ID 1.

The conditions in the receive() function on the destination node then checks, that the incoming message is of type V_VAR1 and its sensor ID is 101 before it prints the received variable.

Here's a compact list of all the relevant getters and setters to manipulate a MyMessage object. For a more detailed overview, refer to the apidocs page for the MyMessage class.

@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.

Yes, this is indeed a problem. China's bad reputation for scams and counterfeit products is of their own making. It's hard to build trust if you always risk running into dishonest and fraudulent sellers. My case is just another example amongst countless others.

I just thought about all those thousands, if not millions of Chinese Arduinos we all buy all the time. And most of them work perfectly fine, so there has to be a legitimate source for genuine ATmegas in China. What could go wrong if I buy the bare chips from the same stores that sell those Arduinos? I expected the MCUs to either work completely or not at all - I either get them for a bargain or get my money back.

And btw, I indeed got my money back. I had a chat with the customer service and they offered me a full refund without hesitation, I didn't even have to ask for it. I spent 8 EUR (~8.5 USD) for 10 pieces (includes coupons). A reputable distributor would have charged about twice as much for this quantity, not even counting in shipping costs, potential small order fees or customs. Worth the extra expense? Propably, but I'm not regretting that I tried my luck either.

Here's a roundup of all combinations I've tried today and their results:

GW Version	Node Version	MY_DEBUG_VERBOSE_RFM69 defined?	wait(50) on node?	TX power regulating?
2.4.0-alpha	2.4.0-alpha	NO	NO	NO
2.4.0-alpha	2.4.0-alpha	YES	NO	YES
2.4.0-alpha	2.4.0-alpha	NO	YES	YES
2.4.0-alpha	2.4.0-alpha	YES	YES	YES
2.4.0-alpha	2.3.2	NO	NO	NO
2.4.0-alpha	2.3.2	YES	NO	YES
2.4.0-alpha	2.3.2	NO	YES	YES
2.4.0-alpha	2.3.2	YES	YES	YES
2.3.2	2.4.0-alpha	NO	NO	YES
2.3.2	2.3.2	NO	NO	YES

Only if the GW is on 2.4.0-alpha and the node (2.3.2 or 2.4.0-alpha) does neither define MY_DEBUG_VERBOSE_RFM69 nor add wait(50) in RFM69_executeATC, the node doesn't regulate the TX power. In all other cases, it does adjust the TX power. If the GW is on 2.3.2 it always regulates.

sensor or sensor ID is synonymous for child ID, one of the many sensors a single node can have. sender is the ID of the node which sent the message.

On the sending node:

#define MY_NODE_ID 7
//                 ^ sender / node ID
[...]
MyMessage msg_LEAK_to_15( 10, V_TRIPPED );
//                        ^^ sensor / child ID
[...]
msg_LEAK_to_15.setDestination(15);
//                            ^^ ID of the destination / receiving node

On the receiving node:

// returns sender / node ID (7)
msg.getSender();

// returns sensor / child ID (10)
msg.getSensor();

So yes, with the changes in your latest code snipped, you should start seeing some serial output.

On a different note: Not that it would change anything here, but l'd like to advise to use the availabe getter and setter functions, whenever possible.

message.sensor==10 works perfectly fine if you want to compare the current value of the variable against 10. But if you accidently omit one of the equal signs, you assign 10 to the variable instead. Bugs like these can be hard to spot - the if-condition would always evaluate true in this case. Using message.getSensor() prevents such mistakes.

If you want to request sensor values directly from other nodes, they all can't be sleeping, because they would have to handle the incoming request. Since you're using an LCD display on the requesting node, I assume that it will always be powered, right?

In this case, I'd suggest to send all the sensor values your're interested in both to the GW and to the LCD node. The sensor nodes can go back to sleep after taking and sending the new measurements and the LCD node will be able to display the new values as soon as they've been sent to it.

On the sensor nodes (5, 7, 10, etc):

#define LCD_NODE_ID 40
void loop() 
{
    send(msgTemp.set(temp)); // Send to GW
    send(msgTemp.set(temp).setDestination(LCD_NODE_ID)); // Send to LCD node
}

Now you have to listen for incoming messages on the LCD node:

#define KITCHEN_NODE_ID 5
#define BEDROOM_NODE_ID 7
bool receivedNewSensorValues = false;

void receive(const MyMessage &msg) 
{
    // Set a flag so that you can update the LCD when needed
    receivedNewSensorValues = true;

    // Receiving temperature from kitchen node
    if (msg.getSender() == KITCHEN_NODE_ID && msg.getType() == V_TEMP)
    {
        kitchenTemp = msg.getFloat();
    }

    // Receiving humidity from kitchen node
    if (...) {}

    // Receiving temperature from bedroom node
    if (...) {}
}

void loop() 
{
    if (receivedNewSensorValues)
    {
        // Update LCD
    }
}

I gave the method with the isopropanol-filled zip bag a try. I soldered the two PCBs in the photo below by hand and have been intentionally messy. I applied lots of rosin based flux, although it wasn't needed, except for maybe the FFC connector. The white solder mask certainly emphasizes every bit of flux.

I put them side by side in a small zip bag with approximately 50ml of isopropanol, squeezed the air out and let the ultrasonic cleaner (filled with water) do its thing for 2 minutes. Here's how the PCBs looked right out of the bath - just gave them a splash of clean isopropanol. No further cleaning.

The board on the left has a little bit of flux residue near the TQFP, in a place where the flux was quite dark and crusty, but the board on the right looks super clean. The isopropanol in the zip bag might be good for another few uses before it has to be replaced. It is already slightly discoloured from the flux.

Anyway, besides the one spot of leftover flux, they look fantastic. Especially the connector cleaned well. And the best of all, for the first time ever my hands didn't feel like I dipped them in a big pot of sticky honey after I cleaned a board!

(Yes, I forgot to solder one side of C10 on the right PCB. Shame on me! I fixed it already.)

---

A cheap ultrasonic cleaner might not be a good choice though...

Apart from this, I also took some time to read about ultrasonic cleaning. Upfront I want to say, that I'll not continue to use my ultrasonic cleaner for this task in the future despite the pleasing results - this was just a test to see how good a simple household-grade cleaner of the 30 - 50 EUR / USD price range does the job.

You may know that ultrasonic cleaners rely on cavitation action to clean. Basically, they create lots of microscopic bubbles which rip the contaminants off the parts when they implode. The frequency which is generated by the transducer(s) determines how big those bubbles are. Lower frequencies cause larger bubbles, which are helpful to clean gross contaminants, like grease and grime from mechanical parts (usually around 25 - 30 kHz). Higher frequencies are less harmful, due to smaller cavitation bubbles and can be used for more delicate cleaning jobs. I read that 40 - 60 kHz are generally prefered for PCBs.

Professional ultrasonc cleaners use frequency sweeping to continuously vary the generated frequency by a few kHz to avoid standing waves in the container, where the cavitation action would be far more vigorous and therefore more harmful to the parts in specific areas. Frequency sweeping seems to be crucial for consistent results with a very low to non-existent risk of damage. Cheap cleaner, like mine, usually don't have this feature and are therefore more likely to damage components. You can test how uniform your cleaner works by placing a sheet of regular thin aliminium foil (10 - 30µm thickness) in a basket, start the cleaning procedure (1min max) and inspect it. It should ideally have a consistant pattern of tiny, roughly equally sized perforations. Here's a photo with three separate passes at 60 seconds each of my cleaner. Looks... totally uniform...?! (Not really)

I also read that a power density below 11 W/liter is considered to be quite save to use. For comparison: my cleaner has a nominal power rating of 50W and a small 0,6l tank. Then there are manufacturers who advice to be cautious when using ultrasonic cleaner, for example MLCCs could crack (TDK, Murata).

Now I'm not dealing with super expensive parts, so it's not that I'm worried to replace a 50 cents component if I get very unlucky, but debugging an invisible / internal fault that is potentially caused during the cleaning process could be a very frustrating task, I reckon.

I think it wouldn't be a bad idea to invest in a higher quality model to clean PCBs. I'll stick with a toothbrush and cotton swaps.

Turning off BOD will save you ~25 µA. AFAIK, if you are going to use MySensors, this is automatically handled in software for you. It turns BOD off before it goes to sleep, which keeps the current consumption low, and reactivates it on wake, which ensures stability.

I wouldn't recommend messing with the fuses manually right away, if it's not neccessary. If something goes wrong or you accidentally set the wrong bit, you risk "bricking" your MCU, which might only be recoverable using a high voltage programmer. Anyway, here's a fuse calculator in case you may need it.

I recommend making yourself familiar with the megaAVR datasheet if you are diverting away from preconfigured Arduinos - it also includes expected current consumptions (see chapters 29, 35) . Nick Gammon has a great guide regarding power consumption, making the topic far more accessible for beginners.

Regarding your serial issues: A baud rate of 115200 is rather high for an 8MHz ATmega328P. Try setting it to 57600, 38400 or even as low as 9600. Both in the code and the serial monitor - they have to match up!

I'm not sure if a node's automatically assigned ID can change in special circumstances (apart from clearing the EEPROM), but as long as you don't care about which specific node sent a message in a node-to-node relationship, this shouldn't be a problem. So it's best to avoid using msg.getSender() on the receiving node.

I just added a static node ID in the example above to better illustrate what each variable means, since you seem to mix up sender and sensor.

I'm still rocking a cute, little AMD Athlon 5350 APU (2GHz, 4C/4T, 15W TDP limit) with just 4GB DDR3. I bought it as a budget solution to learn about Linux and server stuff and never intended it to last for so long, but it's still keeping up just fine. Neither OpenMediaVault (Debian-based), nor Ubuntu Server were causing any hardware-related issues.

It hosts about a dozen of Docker containers and a bunch of natively installed services for everything home automation, data collection and IoT. I have some self-hosted web services running and use it as a DNS server / firewall, NAS for media streaming and as a personal "cloud" storage for four household members. Despite the poor specs, it is powerful enough to serve multiple users simultaneously (DAAP, video streaming or other I/O tasks) while still managing all the network and IoT stuff in the background.

I wonder, where would you get that Ryzen 7 5800U from? Isn't that a non-socketable BGA package meant for notebooks? If I had to build a new system right now, I would spontaneously go for a regular Ryzen 5 (maybe Ryzen 7, if the additional cores are really needed for VMs and such) and undervolt it to make it run more efficient. Depending on the mainboard selection, you can use ECC RAM and get up to 10x SATA onboard, which should be plenty for home use.

@NeverDie Nah, I'm fine. It's always helpful to get opinions and views from others, especially if they are more experienced in the matter, if only to set one's own viewpoint straight. I'm grateful for all you guys replies, but I don't feel like bothering Microchip with this.

Regarding Nordic - besides the circulating copies / clones (like the SI24R1), I guess it's also not helping that they are fabless, unlike Atmel / Microchip, in which case it seems totally reasonable that the various fabs may have slight marking variations. I just didn't expect that from those ATmegas which seem to have been produced in one and the same factory.
But it's certainly a neat touch from Nordic to offer a free test.

@Danielo-Rodríguez I used D0 (GPIO16), D3 (GPIO2) and D4 (GPIO4) on my NodeMCU-based GW for status LEDs. Since the pin definitions of the NodeMCU and D1 mini are the same, this should work on the D1 mini as well. Just make sure to connect them to VCC, not GND. If either D3 or D4 are pulled low, the ESP won't boot.

Unfortunately, I don't have a test setup running right now, otherwise I would quickly whip up and test two minimal example sketches.

But here are some snippets that should include everything related to node-to-node communication you need. My best advice at this point, if it still confuses you, is to get rid of all the magic numbers in the code and define macros / constants.

On the leak detector node, you need the following bits:

bool leakState = false;
bool previousLeakState = false;

#define LEAK_CHILD_ID 0 // 0 to 254
#define LEAK_CHILD_ID_TO_NODE 100 // 0 to 254
#define LEAK_TARGET_NODE_ID 15 // The ID of the node you want to report to

// Setup two separate messages. One reports to the GW, the other to the target node
MyMessage msgToGw(LEAK_CHILD_ID, V_TRIPPED);
MyMessage msgToNode(LEAK_CHILD_ID_TO_NODE, V_TRIPPED);

void presentation() 
{
	// Register and present sketch and sensors
	sendSketchInfo("Leak Detector", "1.0");
	present(LEAK_CHILD_ID, S_WATER_LEAK);
}

void setup()  
{
	// Set the destination for msgToNode permanently to the target node's ID 
	// msgToGw doesn't need that; it defaults to 0 (=GW)
	msgToNode.setDestination(LEAK_TARGET_NODE_ID);
}

void loop() 
{
	// Check if things have changed
	if (leakState != previousLeakState)
	{
		// Report new state to GW and target node
		send(msgToGw.set(leakState));
		wait(100); // Optional, but a short pause inbetween can't hurt
		send(msgToNode.set(leakState));
		
		// Update state
		previousLeakState = leakState;
	}
}

This will inform the GW via msgToGw as well as the the node with the ID 15 (LEAK_TARGET_NODE_ID) via msgToNode about the updated leakState.

The GW will receive this message with the child ID 0 (LEAK_CHILD_ID), node 15 will receive it with the child ID 100 (LEAK_CHILD_ID_TO_NODE). You do not need to change the child ID you send to the destination node - you can keep using the same as for the GW. Just note that you can change it.

On the target node, you need this:

bool leakState = false;
bool previousLeakState = false;
#define LEAK_CHILD_ID_INCOMING 100 

void loop() 
{
	// Check if leakState has changed
	if (leakState != previousLeakState)
	{
		// Do something
		
		// Update state
		previousLeakState = leakState;
	}
}

void receive(const MyMessage & msg) 
{
	Serial.print("Incoming message... ");

	// Filter out our message
	if (msg.getType() == V_TRIPPED && 
		msg.getSensor() == LEAK_CHILD_ID_INCOMING)
	{
		// Update the local leakState variable
		leakState = msg.getBool();

		// Print some infos
		Serial.println("is a new leak state!");
		Serial.print("From (Node ID):");
		Serial.println(msg.getSender());
		Serial.print("Child ID: ");
		Serial.println(msg.getSensor());
		Serial.print("State: ");
		Serial.println(leakState);
	} else 
	{
		Serial.println("is something else. :(");
	}
}

Hope I didn't miss anything.

Once you got it working, it's best to remove most if not all serial prints from the receive function, as it's generally bad practice and can cause various problems.

@NeverDie said in Best PC platform for running Esxi/Docker at home?:

Were you using it for Esxi or Docker?

I do not use any hardware virtualization / hypervisors. Just a regular Linux distribution as a host running Docker containers and other stuff.

Is that some kind of carrier that it's affixed to, or is it all BGA on the other side?

AFAIK, all Ryzen CPUs ending with an U or H are soldered BGA packages for the mobile OEM market. U indicates low TDP variants for long battery runtime, whereas H or HS stands for high performance setup.

@skywatch

Sorry, I don't quite follow. I don't think you want to say that the snippet is missing the MySensors.h include and such, are you?

@pw44 No, this isn't a good idea. You should have all status LEDs in either source or sink configuration, or some LEDs will be inverted (lit by default, off when there is activity).

D3 and D4 must to be connected like this to not prevent the ESP from booting: GPIO - Resistor - LED cathode - LED anode - VCC. D0 should be connected equally, even if it doesn't matter for the ESP's functionality.

Besides that, if you don't use I2C, you should also be able to use D1 (GPIO5) and D2 (GPIO4) for status LEDs, inclusion mode button, etc.

Glad you got it working!

1. The order of the functions in the sketch doesn't determine their execution order, which is managed behind the scenes by the framework. You could place receive() right below the mysensors.h inclusion if you wish.

2. They don't. That's why I showed you how to assign a different child ID. You could assing a unique ID per node-to-node-message to make them identifiable.
   If multiple node-to-node-message end up having the same child ID, you would have to factor in other variables, like getSender() to tell them apart. Let's say you have three nodes (IDs 1, 2, 3) sending a boolean to a fourth target node and all messages have the same child ID of 0, you could tell them apart like this:

   #define LEAK_CHILD_ID_INCOMING 0
   // [...]
   void receive(const MyMessage & msg) 
   {
   	// Message is what we're looking for
   	if (msg.getType() == V_TRIPPED && 
   		msg.getSensor() == LEAK_CHILD_ID_INCOMING)
   	{
   		// Find out where it's from
   		switch (msg.getSender())
   		{
   			case 1: // From node ID 1
   				leakStateNode1 = msg.getBool();
   				break;
   			case 2: // From node ID 2
   				leakStateNode2 = msg.getBool();
   				break;
   			case 3: // From node ID 3
   				leakStateNode3 = msg.getBool();
   				break;
   			default: // From GW or 4 - 254
   				break;
   		}
   	}
   }
   

   But again, since you're using automatic ID assignment - I'm not sure if node IDs can change under specific circumstances. So If you make use of getSender() you may want to consider assigning static node IDs.

I get that efficieny is important for a device that runs 24/7, but looking at the options you have with a 5800U, I think you sacrifice a lot. How do you add hard drives for storage, via USB3? What about RAID? How do you know if the laptop's thermal design is sufficient for 24/7 uptime?

Do not focus too much on the nominal TDP. It is basically just an approximation for the cooling solution required to achieve the rated performance of the CPU. In the specific case of AMD Ryzen CPUs, the rated TDP roughly equals the power draw in P0 state, which is the highest active power state the CPU can be in.

For example, a Ryzen 5 5600X rated at 65W may draw 60 to 75W (once the thermal limit is reached and everything is settled in) under high demanding workloads (prime95 and such). Modern CPUs are smart enough to switch to quite efficient P-states when they have nothing to do, lowering the clock to the sub-GHz range, drastically reducing the core voltage. So if the CPU is idling, it may only draw 10 to 15% of the rated TDP - and a home server will likely idle 95% of the time.

At this point, other components (mainboard chipset, hard drives and other peripherals, power losses of the power supply, ...) might start to contribute more to the total power consumption of the PC than the CPU itself. And I haven't even mentioned that you could underclock (which doesn't void warranty) the CPU the increase the efficiency even further.

@skywatch Got it, you pretended to be a newbie all along. Was it too boring to show your intentions right away?

I understand your point, but I guess that brings us back to the discussion we had a few months ago about the state of the documentation / guides and how beginner friendly it needs to be and where it starts to be too verbose. IMHO, in the context of that page, it's fine and it should be clear that it isn't a complete sketch.

If I can come up with a meaningful sketch that makes use of both timed and external interrupts without using additional libraries and such, I'll post it so that someone with rights to edit those articles can update it if they want.

Edit: Well, not that meaningful, but it brings the point across and isn't too long:

#define MY_RADIO_RF24
#include <MySensors.h>

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

#define INT_PIN 3
#define LED_PIN 5
bool ledState = false;

#define SLEEP_TIME 9000000 // 15 min
uint32_t sleepTime = SLEEP_TIME;
int8_t wakeupReason = MY_WAKE_UP_BY_TIMER; // Initial value, will be set by sleep after the first run

void presentation()
{
	sendSketchInfo("Sleep + Interrupts", "1.0");
	present(CHILD_ID, S_BINARY);
}

void setup()
{
	pinMode(LED_PIN, OUTPUT);
	digitalWrite(LED_PIN, ledState);
}

void loop()
{
	if (wakeupReason == digitalPinToInterrupt(INT_PIN)) {
		sleepTime = getSleepRemaining();
		// Do interrupt-triggered stuff here
		// Sends the pin state when woken up by external interrupt
		send(msg.set(digitalRead(INT_PIN)));
	} else if (wakeupReason == MY_WAKE_UP_BY_TIMER) {
		sleepTime = SLEEP_TIME;
		// Do periodical stuff here
		// Toggles the LED every 15 minutes
		ledState = !ledState;
		digitalWrite(LED_PIN, ledState);
	}
	wakeupReason = sleep(digitalPinToInterrupt(INT_PIN), CHANGE, sleepTime);
}

@pw44 If you are using the "big" WeMos D1 - the one in the shape of an Arduino Uno - then yes, that looks right to me. This file contains the pin definitions used for this board. But you may have to wire the LEDs to different pins in this case, because D4 / GPIO4 conflicts with the default assignment for CE when using an NRF24 transceiver and D3 / GPIO5 conflicts with DIO0 when using an RFM radio according to the Connecting the Radio guide.

If you want to try using the same GPIOs that worked for me on the NodeMCU (2, 4 and 16), you may connect the LEDs to D9, D14 and D2.

You may also want to read the book that @mfalkvidd recommended or take a look at this ESP8266 pinout reference to see what pin does what.

The D1 mini - the board that the OP uses - has different pin definitions, which are listed here and are similar to the NodeMCU I was using.

In general, I think it should be fine to use the alias D1, D2, etc for the pins. No need to use the GPIO number here.

I have not tested it myself, but I think getSleepRemaining() is what you are looking for. It returns the time in ms that is remaining in the current sleep cycle if the device woke up by an interrupt. This seems to be implemented for AVR (this includes Arduinos) only.

Something similar to this should work:

#define INT_PIN 3
#define SLEEP_TIME 9000000 // 15 min
uint32_t sleepTime = SLEEP_TIME;
int8_t wakeupReason = 0;
void loop()
{
	if (wakeupReason == digitalPinToInterrupt(INT_PIN)) 
	{
		sleepTime = getSleepRemaining();
		// Report sensor status here
	}
	else if (wakeupReason == MY_WAKE_UP_BY_TIMER)
	{
		sleepTime = SLEEP_TIME;
		// Report battery level here
	}
	wakeupReason = sleep(digitalPinToInterrupt(INT_PIN), CHANGE, sleepTime);
}

Since sleep() returns the wake up reason, we can check whether it was caused by the external interrupt on D3 or because the timer ran out and set the sleep time for the next period accordingly.

So, a node with a sleep time of 15 minutes, which is interrupted after 10 minutes, should send the sensor status and go back to sleep for another 5 minutes, report the battery status and reset the sleep timer to the full duration of 15 minutes.

Building quiet PCs is so addictive. Once you're used to it, every little rattling becomes an annoyance. It didn't took long until I had to get rid of all spinning HDDs in favor of SSDs. And as soon as everything was dead silent... I bought myself a clicky mechanical keyboard, oh well..

Nanoxia Deep Silence and Fractal Design Define are indeed nice sound-insulated cases for quiet builds with plenty of space and features.

For silent cooling, I can recommend be quiet (especially the Silent Wings fans) and Noctua (basically everything). The latter is quite pricy though.

I don't think there's are direct causal relationship between the quality of a documentation and the number of users asking for help on a forum.

People usually register to get help and you'll likely find that most people in this (or any) forum asked a question in their first post (me included) and most of them never came back after their issue has been solved or they lost interest. This forum has almost 10k registered users, of which 8k wrote five posts or less. From this we can't infer that most users trying to use MySensors encounter problems, nor that the documentation is flawed. That's just the nature of a support forum, or any forum, really.

Regarding this forum specifically, my gut feeling tells me that most questions are related to connection issues between nodes, which are usually caused by wrong or flimsy wiring, weak power supplies, too much noise, range issues, etc. The solutions for those issues are documented in articles as well as the FAQ, but people are still asking.

Maybe my gut feeling is wrong and it might be worthwile for us to browse through the troubleshooting forum. Comparing what people actually asked or were looking for and comparing it to how well those topics are covered in the articles and guides might be a more practical approach to improving the documentation.

@GardenShedDev I just uploaded a basic blinky sketch with ArduinoOTA and also my trusty old WiFi-MQTT-GW sketch with MySensors 2.3.2 and ArduinoOTA - which basically looks just like the one you posted above, minus the yield() in the loop - to a spare NodeMCU (ESP-12E).

OTA-uploading of a new sketch both via PlatformIO and manually from the command line worked right away - with and without MySensors - but it always took the ArduinoIDE (1.8.12 and 1.8.13) a few minutes and a restart (1.8.12) to display the NodeMCU in the Tools > Port menu list as an upload target. After that, one-click uploads through the GUI worked just fine as well.

My guess would be that this is an ArduinoIDE or maybe network issue, but not related to MySensors. Not sure how to address that at the moment. Your sketch seems fine though. Do you get a reply if you try to ping the IP address of the ESP?

If you have or want to try your luck with PlatformIO, here's a minimal config for OTA uploads:

[platformio]
default_envs = ota

[env]
platform = espressif8266
board = nodemcuv2
framework = arduino
lib_deps = MySensors@2.3.2
monitor_speed = 9600

[env:ota]
upload_port=192.168.178.xxx
upload_protocol=espota

[env:uart]
upload_protocol = esptool
upload_port = COM4

Make sure to insert the correct IP and COM port. To upload an initial sketch via serial run pio run -t upload -e uart.

Hi @niclas,

you could create a customize.yaml file in the root folder of your HA installation (the same folder with configuration.yaml, automations.yaml, etc in it) and add the following to it:

sensor.mysensor_60_3: 
  friendly_name: Barometer
  unit_of_measurement: hPa

You might have to restart HA afterwards or reload the config. This deals with the issue directly in HA.

The first line is the entity of your pressure sensor with the format of sensor.sketchname_nodeID_childID. It should be listed under the following url: yourHAip:port/developer-tools/state.

friendly_name is optional and changes, well, the name that is displayed under the sensor icon and unit_of_measurement tells HA what unit your values represent, so that it can display a suitable graph. Since you mentioned a value of 954.3, I assumed hPa is the unit you're looking for.

Here's a link related to this topic in the HA documentation.

Hope that works for you.

Hi @edweather, I have no experience with NodeManager, but I had a quick look at the source code.

setValueDelta is a member of the Child class, which manages all the kinds of data common to all sensors, like their IDs, getting and setting sensor values and their precision, thresholds, etc. This is why you specify it for every children separately, if you're not happy with the default value.

setPulseFactor on the other hand is a public member of SensorPulseMeter which SensorRainGauge inherits from. It is not specific to any child of the sensor. You are meant to call it directly on the sensor's class instance, like so: rainGauge.setPulseFactor(0.36);

For the same reason I think you also want to change

  rainGauge.children.get()->setSleepInterruptPin(3); //Sleep interupt pin
  rainGauge.children.get()->setInterruptDebounce(500); //debounce

to

  nodeManager.setSleepInterruptPin(3);
  nodeManager.setInterruptDebounce(500);

because both are public members of the NodeManager class.

I think that should work for you. If I'm totally wrong, just ignore what I wrote.

@skywatch Huh! I didn't know there was a ATmega168 with a V and had to look it up.

Maybe I'm wrong, but comparing datasheets of both 168-variants and looking at some of the older Arduinos, I guess you could use a regular ATmega168 bootloader without any suffix. The Arduino folks seem to have done that with the 168V-based Lillypad for example.

MiniCore for example provides a bootloader for a 1MHz 168 and the fuse settings (for BOD) seem to match as well.

You may have a look at that unless you found a suitable 168V bootloader in the meantime.

Edit: replaced all 186 with 168.

@GardenShedDev ArduinoOTA should not be confused with the MySensors-specific OTA features to upload firmware via other transports (like NRF24) to remote nodes. There's nothing special about ArduinoOTA when used alongside MySensors. As far as I know, MySensors doesn't mess with it at all. It's completely separate.

Here's a dependency graph from a basic ESP8266-GW sketch with ArduinoOTA:

|-- <MySensors> 2.3.2
|   |-- <Wire> 1.0
|   |-- <SPI> 1.0
|   |-- <EEPROM> 1.0
|   |-- <ESP8266WiFi> 1.0
|   |-- <ESP8266SdFat> 1.1.0
|   |   |-- <SPI> 1.0
|-- <ArduinoOTA> 1.0
|   |-- <ESP8266WiFi> 1.0
|   |-- <ESP8266mDNS> 1.2
|   |   |-- <ESP8266WiFi> 1.0

That being said, I've now tried to replicate this issue again with different ESP8266 cores from version 2.5.0 to 2.7.4 and MySensors from 2.3.0 to 2.3.2. It's always the same behaviour: It may take the ArduinoIDE a minute, a restart of the IDE or an hardware reset of the NodeMCU to list the device. But in the end, it always connects, uploads and executes the new sketch properly. In any case, I can always OTA-upload manually as soon as the ESP is online, no matter if the ArduinoIDE lists it or not.

I'm not sure what's causing this issue for you, but I honestly doubt that the MySensors framework is the culprit.

The static IP configuration from your earlier attempts might still be retained. Try adding this to the beginning of setup() for test purposes:

WiFi.disconnect(true);
delay(1000);
WiFi.begin(MY_WIFI_SSID, MY_WIFI_PASSWORD);
WiFi.config(0u, 0u, 0u);

Or clear the whole flash, in case some other WiFi related stuff may still be stored (Tools > Erase Flash > All Flash Contents).

You may also try OTA-uploading a sketch a different way. From a terminal, this should look like this:

path/to/python3 path/to/espota.py -i 192.168.esp.ip -p 8266 -f path/to/sketch-binary.ino.bin

On Windows, you should be able to find the ArduinoIDE-managed python3 in %localappdata%\Arduino15\packages\esp8266\tools\python3\xxx-version-string/python3 and espota in %localappdata%\Arduino15\packages\esp8266\hardware\esp8266\xxx-version-string/tools/espota.py. On Linux and macOS, that should be ~/.arduino15/... or ~/Library/Arduino15/...

The ArduinoIDE saves binaries to some temp directory by default, I think, but you can use Sketch > Export Compiled Binary to save it in the same folder as the sketch.

In your sketch you present a moisture sensor with a child ID of 0 to Home Assistant, but you do not send any actual values for this sensor in your loop. As long there is no data, Home Assistant will not display anything in the web interface. Try adding send(msg.set(sensorValue)); to your loop and see if this does what you expect.

---

The log message from Home Assistant is nothing to worry about by itself. When a node presents its sensors, Home Assistant looks up if they are already known and listed in your persistance file.

If no entry with the presented child ID exists for a specific node in the persistance file, Home Assistant will add it and log to the console, that a new device has been added.

Otherwise, if a child with the presented ID already exists, it does nothing but log the warning you got. You can safely ignore this as long as the sensor type stays the same, but if the newly presented sensor is of a different type, Home Assistant will not overwrite / change it to the new type and it will not show the new sensor values in the web interface. In this case, you would have to remove the conflicting child object manually from your persistance file, reload your configuration and present your sensors again.

Hi @darknicht66

According to this PR (third point in the list), adding sensor.children.get()->setUnitPrefix("YourUnit") should do the trick. You may need to install the current development branch of NodeManager to use this. Hope this helps!

The URL is in an inline code HTML element and the CSS rule #article code {white-space: nowrap;} prevents long lines from breaking the layout, causing the (visual) truncation depending on the window size. Double-clicking or marking the whole line with the cursor gives you the full link, but you can't simply click on it to open the URL. A hyperlink would wrap (and be clickable).

I assume this is only a temporary solution. It might be better though to replace it with a hyperlink tag or better, embed it like the external measurement example in the section below it (once it's added to the examples repo).

@mfalkvidd Okay, understood. Managing external libraries in ArduinoIDE projects can be cumbersome and confusing. Just brainstorming here - two ways of clarifying that external libraries are required in a provided example sketch:

• After including an external library, add a conditional #error preprocessor directive that checks if the library-specific header guard is defined. This doesn't address backwards compatibility issues though:

#include <Vcc.h>
#ifndef VCC_H
#error You need to install Arduino_VCC version 1.x (URL)
#error How to install libraries in ArduinoIDE: (URL)
#endif

• Provide a "Notice" box or something like that above the embedded sketch on the website: (quickly hacked together):
  

If I understand you right, this happened:

-> You created a new node with ID 6 as a relay and connected it. Home Assistant didn't list the new node.

Most likely, because you didn't send an initial value. If a sensor / child has not sent a value at least once, HA won't display it, because there is nothing that it could display. (No value, or null, isn't the same as a value of 0 / zero. The latter could be interpreted as "off", but not the former.)

Since the MySensors integration is now configurable via the UI, every node must be registered in Home Assistant's entity registry. That means, that every MySensors node and its children get a persistent unique_id, which doesn't change after uploading a different sketch.

-> The relay appeared in the UI after some time.

You did something to trigger the relay or updated the sketch to send the relay state at least once when you were researching the problem. Now that HA has a value to associate with the entity, it is able to display something in the UI.

-> You uploaded a different sketch for a motion sensor to the Arduino, but kept using the same node and child ID.

Home Assistant recognized that this is the exact same device as before, because the unique_id didn't change and as far as Home Assistant is concerned, you are not supposed to change this ID.

The data stored in the entity registry has precedence over other data sources like the mysensors.json file, so HA will continue to treat every sensor with the same child ID on node ID 6 connected to the same gateway as a relay and name it "Relay 6" by default.

Some possible workarounds are:

• Rename the "Relay 6" in the Home Assistant UI.
• Delete the entity of the relay sensor from the UI using the "DELETE" button in the lower left corner of the modal window. Then power up the Arduino with the new motion sensor sketch.
• Shut down Home Assistant and delete the registry entry of the relay sensor manually from the core.entity_registry JSON file (located in config/.storage/). Be sure to backup the file before doing so!
• Choose a different node / child ID for the motion sensor and "disable" the relay entity in the UI.

I think, since MySensors nodes are now uniquely registered in Home Assistant, it should be "best practice" to statically (manually) assign node IDs and be mindful about it. Like, use different node IDs for different node types to avoid conflicts with the registry. If you ever used ID 5 for a temperature and humidity sensor and you stopped using it, avoid reusing the same node ID for anything else than another temperature and humidity sensor node.

Personally, I use ID ranges for nodes with the same function. Like, all node IDs from 30 to 49 are reserved for door and windor contact sensors.

By the looks of it, you are sending multiple V_Types (V_STATUS, V_VAR1, V_VAR2) to a single child sensor ID (2). I guess this is what's confusing Home Assistant here, because it's inconclusive which data set should be displayed for this entity. Try splitting the V_Types into individual child sensors.

Quick simplified example:

#define CHILD_ID_STATUS 1
#define CHILD_ID_VAR1 2

// Choose a unique child ID per v_type
MyMessage msgStatus(CHILD_ID_STATUS, V_STATUS);
MyMessage msgVar1(CHILD_ID_VAR1, V_VAR1);

void loop() {
  send.msgStatus(valueStatus);
  send.msgVar1(valueVar1);
}

Providing your sketch might also help troubleshooting.