I see that the the nRFDoctor has a menu. Perhaps one of the menu items has to be selected?

@ben999 said:

mentions

I suspect that the library has been included in the Arduino repository. I used the IDE library manager to install it.

@ben999 said:

At that point did you upload that sketch to a nano+nrf for testing ?

I haven't done any hardware testing. I'll leave that for you.

@ben999 said:

"mklink" thing is specific to Windows right ?

Yes, mklink.bat is for Windows only. This script is the linux equivalent.

# assumes the existence of the folder shared in the current directory.
cd nRF24DoctorNode
ln -s ../shared shared
cd ..
cd nRF24DoctorGateway
ln -s ../shared shared
cd ..

I'm thrashing on this, too, so I downloaded it and I compiled it.

Downloading:

1. From the web page I clicked on [Code] and then downloaded the zip file.
2. I extracted the zip file to my Arduino directory.
3. In a dos box (command line) I changed to Arduino\nRFDoctor-master
4. I executed the batch program mklink.bat which created symbolic links in both nRF24DoctorGateway and nRF24DoctorNode to their sister directory shared. This is needed so that the compiler can find the project specific libraries, eg RadioConfig.h

Then I opened nRF24DoctorNode in the Arduino IDE 2.3.10

When first compiling, there were many libraries required which I installed.

After all the libraries were installed, the code had the compiler check a value and if it was incorrect, it threw an error. When the line #define _LCDML_DISP_cfg_max_rows 2 was added to the the library LCDMenuLib2.h at line 42, the error no longer occurred. (Was this a good thing? Perhaps the line should have gone just before the error check?) This library is found in the directory Arduino\libraries\LCDMenuLib2\src

Subsequently The compiler recommend changing the line 28 of CharLcdMenu.ino (tmp = LCDML.MENU_getObj()->getChild(LCDML.MENU_getScroll());) to tmp = LCDML.MENU_getRootObj()->getChild(LCDML.MENU_getScroll());

After that, the code compiled.

Home Assistant is my controller. It runs in a virtualbox under linux on a refurbished PC. On that same computer I run an MQTT broker (not using HA's)

My gateway, which uses MQTT for transport, runs on an RPi zero 2W running Raspberry Pi OS. It also controls my irrigation relays.

I also have a serial gateway which has no radio network which is its own node for "pushing" the buttons on a remote control. This gateway essentially gives a PC digital IO.

Yeah, you need the sketch name.

I found that wait() was required pretty much after every send. I don't why exactly, I suspect the the send commands were overrunning the previous send command.

I vaguely remember that the RF24_PA_[power level] was given a different name. to something different. Basically the power level is 0,1,2, or 3 (MIN, LOW, HIGH, or MAX). see docs

To get it to compile, put this (a hack) line in
#define RF24_PA_LOW 1
before line 47
#include "shared/RadioConfig.h"
or before
radio.setPALevel(RF24_PA_LOW);

I had forgotten about this. Maybe the problem is that that power level is set to low. I see in RadioConfig.h it's set to LOW. This is done because the two radios could be close to one another and they would overdrive the other if they're set to MAX

Another thought (my little gray cells are not firing on all cylinders) It seems to me that line 47
#include "shared/RadioConfig.h"
should be after line 59
#include <MySensors.h>
because the MySensors library is where the PA variables are set.

I hope my rambling here hasn't further complicated the issue.

@ben999

@ben999 said:

very basic sketch

My guess is that because you're not using the LCD in the basic sketch that talking to the LCD is causing radio interference.

To test this theory and assuming you have the LED connected, the LCD code could be replaced with flash-code code.

My technique for doing this replacement is to use compiler directives to remove the LCD code and add flash-code code.

To remove the LCD code, create a new compiler flag
#define LCD_ENABLE
Surround all LCD code with

#ifdef LCD_ENABLE
...
#endif

Then comment out the definition line which disables the LCD.

Create another new compiler flag
#define FC_PIN 4
and comment out both the compiler directives that create TRIGGER_PIN and LED_PIN

At the point in the existing code where the LCD is to display the quality, put a call to your new routine, This call will pass the quality number to the code that generates a flash code. So this new code can be easily disabled, surround your code with:

#ifndef FC_PIN
...
#endif

Yes, I make a huge assumption that you understand this (compiler directives, flash-code, etc.). If you don't, I, or others, can help out, but you'd learn more if you did it on your own.

The nRF24 is good for short distances ~10m. That distance can be extended because nodes can also be a repeater to the gateway.

I'm using an RPi zero 2W for my gateway (which is also my irrigation controller.) Can you reach your greenhouse with WiFi? This may work for you.

I'd look at the RFnano that has the nRF24 integrated. It costs about more than a Nano and nRF24 separately, but what you gain is no wiring and no wiring failures.

I tried to used this moisture sensor and it corroded within a year. DHT-12 (digital humidity and temperature) can be off as much as 4°C per the specs and suffers from the same corrosion challenge.

Speaking of corrosion, be sure to "paint" all your electronics with electrical lacquer sealer (but not on the sensors)

You have to consider how you're going to power your sensors. I'm not a big fan of batteries because you have to jump through a lot of hoops to get the most out of the batteries. On the flip side, you'll have to run 5V to all your sensors. This is my [pathetic] attempt at a remote soil sensor

What are you looking to monitor and/or control @robert-fletcher?

There is a collection of techniques that can reduce energy consumption of the Nano. (eg, remove power applied LED) I've read about µA's during sleep periods.

The ESP-12F clearly achieves this and can be a MySensors by adding a radio. Note that if WiFi is not disabled, savings are probably lost because the WiFi is energy hungry. This would have me leaning towards MySensors rather than ESPHome.

My experience tells me that the Nano is more durable than the ESP.

Another tip: If you're going to put your sensor in a harsh environment, after you have assembled it, "paint" it with electrical lacquer.

@mfalkvidd After giving this some thought, wouldn't that imply that at sufficiently low flow rates, the the meter would not detect any flow. A leaky faucet? While I'm pretty sure that my pump can't pump that slow, the pressure would drop, eventually triggering the pump to start. A leak could be detected by periods of pumping that are very short? An experiment could be run to see how much water must be released to trigger the pump to start. The time between pumpings could then be used to determine this flow rate.

And after reading this, I see I have to much time on my hands which could be used to address more pressing issues.

I have a gravity fed irrigation system and I'm measuring how much water I pump to the top of the hill, which is effectively how much water is used in irrigation. I also have a well and measure the water pumped from the well.

The former is a 3/4" pipe and the the pulses-per-liter calculation is a constant. The other is a 1" pipe which is a constant with an offset. Which doesn't make sense to me. I'm ignoring the offset which will probably result in an error in the exact amount of water I'm pumping. Not really a big deal.

More information showing the versatility of your journey

From my perspective, the choice between ESPHome and MySensors comes down to what kind of coder you are. If you are comfortable with python, you should go with ESPHome. If you're comfortable with compiled programs, like c++, go with MySensors with the Arduino IDE. The learning curve for one or the other depends on from which background you come.

ESP devices use WiFi to connect. I have found that typical home routers (my experience is with Asus) have a problems when you get to about 25 devices WiFi connected devices. The symptoms are devices have problems connecting or disconnect intermittently.

MySensors is not well supported in that there are only a few people that check in regularly. That said, the documentation is very good and answers can be found on this forum. In a sense, self supported. It provides a pretty rock-solid protocol/API. It is your hands-on, bit-banging, low-level code that you do to make your sensor/actuator go.

ESP devices have the ability to be updated OTA (over the air) and are supported in MySensors

I find that ESPHome blends the protocol/API with the actual function which can make it difficult to debug. Natively, it is lacking some capability. This lack can be covered with JSON and Jinja, which steepens the learning curve. But, again, a python background is helpful.

Tasmota is another way to go when using ESP devices in Home Assistant. It is a state-machine (which works well for simple devices). The protocol/API is rock-solid. It has templates for a lot of devices and it just works. After initially programmed, updates are OTA. I have even updated a Tasmota programmed device with Arduino IDE OTA code and vice-versa.

With HA as your controller, none of the technologies are mutually exclusive!

You have three ways to for the gateway to communicate to Home Assistant (HA), serial, ethernet, and MQTT.

It comes to this: A serial gateway will be in very close proximity to the HA Green. It is very simple to set up. ethernet or MQTT can be anywhere there is ethernet or WiFi, but not so simple to set up.

The latter two require ethernet connectivity hardware added. This makes the configuration much more complicated and, if going this way, I'd recommend the RPi zero 2W with your radio of choice running Raspberry Pi OS as your gateway. The gateway software runs in the OS (I run this set up).

The serial gateway is a wired connection to your HA Green and the HA Green would power it. The location of your HA Green/serial gateway probably take some experimentation.

The downside is the range of your radio. Fortunately, with repeater nodes or nodes that also act as repeaters, too, this isn't too bad. I find the range, line-of-sight, no obstructions about 10m. Or, 3m through 1 wall.

I am unfamiliar with Sensebender. Googling it I find one from Itead one from OpenHardware. I'm not finding much in the way of documentation. :(

I am familiar with the RF-Nano (Arduino Nano compatible with nRF24 built in) and would offer much the same capabilities as the Sensbender. The range on the RF-Nano is a bit less than that of the stand-alone nRF24.

The Nano is powered from the computer, though from what I can glean from the docs, the Sensebender would also require a serial-to-USB adapter (use 3V3 pin on adapter for power). This is amazingly simple hardware.

The Nano gateway can also have sensors. This is very cool for me because I run HA in a virtual box under Ubuntu on a refurb PC. The serial gateway is a Nano compatible and I use it to "push" buttons on a remote. I'm not using a radio at all. Essentially the Nano and MySensors gateway software gives me I/O ports for my pc.

Let us know how your project goes.

First, my sympathies and empathies. Remember, this, too, shall pass. Perhaps you will become a grandparent and get your revenge by spoiling the grandkids rotten.

Cool project! I use the same flow meter and have found it very reliable. I, too, think the idea of realtime feedback is much better than the shut-off valve which would also double the cost of the project.

And, if you do become a grandparent, you can offer to remove and install it in your offspring's abode. ;)

-OSD

nice! I'm happy that there is another radio to use

As we all know, the nRF24 works pretty well, but there is a lot of device-to-device variation. This would be a nice thing to have when debugging the network.

@juliefen will you be creating a github project with schematic, board layout, code, construction tips, theory of operation, calibration and operating manual, examples, etc.?

I had turned off debug on my MQTT gateway (RPi zero 2 w) and I had a similar experience. I didn't even consider the problem was on the radio.

I did this because messages weren't being received by the MQTT broker. Taking out DEBUG made it worse. subsequently, I put wait (not delay) statements after each send. It's all working well for me.

For those that don't know, delay is blocking, that is, nothing gets processed during the delay. wait, (a MySensors library function?) is non-blocking. That is, MySensors will continue to process outgoing and incoming messages while waiting.

I have learned the hard way, many times, "If it's not broken, don't fix it". MySensors fills a niche, very low power, very low cost, sensors (albeit, DIY). The range is about the same as Bluetooth. The data is usually a boolean or an integer.

So let us not say, abanddoned but at a development plateau. A mature technology that still has legs.

This is really not a MySensors topic!

Just by the way present you request indicates that you are way over your head. I have a degree in electrical engineering, the study of electrical energy generation, transmission, distribution, etc. and substation design would take me years of study to be competent.

Any discussion about electrical energy delivery start with safety. Fuses and breakers, basically, but these have to be able to break 1000's of amps ... not a trivial task. The trick is to bring down the circuit without damaging other equipment on the circuit. Just detecting a fault is a doctoral candidate dissertation.

Basic components: transformers, breakers, switches and a lot of instrumentation.

Voltage levels are pretty much already defined because the equipment available is already set for those levels. Transformer basic rating is KVA, input and output voltage. There's a lot more to it ... a lot more.

As far as books for beginners ... I can't imagine that there are any. There are probably books for people who have been in the industry for more than a few years.