The HA forum has a lot of helpful people, though there is a small cadre of people that are a little arrogant. Thicken your skin and ignore them.

I use old/refurbished pc's desktop or laptop. 4GB RAM is do-able, but 8GB is better. 500GB disk is fine, even 128GB. 4 CPU cores is good, too.

I install ubuntu linux on the machine. Then I install Virtual Box

HA has the installation instructions on how to install HAOS into the virtual box. Use half your memory and CPUs

You have to tunnel your USB port into the Virtual Machine (VM) ... The USB has to be plugged in when you do the VM configuration.

I have several dongles on mine: USB/serial for MySensors Serial Gateway, Sonoff Z-Wave, Sonoff Zigbee.

I recently discovered why my one Zigbee device wasn't working ... the dongle fell off the USB extension cable (necessary on Z-Wave, too, to minimize RF interference)

Let us know how you are doing as you progress.

Are you running HA on the RPi 3? There have been many reports of HA bloating to beyond the capabilities of the RPi. If this is the case, you'll have to install HA on another computer.

I run HA in a virtual box which runs under the Ubuntu OS on a refurbished PC. (You can use an old laptop, too.) I believe that you can run HA on a PC "bare metal" too. If you have to go that route, we can help you.

Glad to help. Cursing is pretty much required, especially if you've done something stupid.

I can't help you with a radiation pattern. I have put all the radios vertical and have been satisfied with the results

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