Posts made by KevinT

Hi OldSurferDude,
I just read through your Energy Meter documentation. Nice work. It gives basic theory and calculations. I've been thinking about building an energy meter for a while now. I'll use this as a reference. Thanks.

Wow, you're going to be busy. Hope all goes well. Give us an update when you're finished.

A little Halloween fun. I've added LED strip lights to an old Halloween plastic ghost and jack-o-lantern and automated switching them off/on using a MySensors node.

@kiesel Thanks for the schematic.
For the decoupling cap, it should be as close to the 3.3V & Gnd pins of the radio as possible.
Keep us posted, thanks.

@kiesel Looks like you are well on your way.
If you post a schematic, you'll likely get more feedback.
If you are using one of those Chinese step up converters to 3.3V, I found I had to add a 1 uF cap on Vin to get good performance at no load.

Most designs I've seen also have a 0.1 uF decoupling cap at the power connections to the radio.

I can't tell where you are connecting the door switch, directly to an unused pins on the pro mini?

One limitation to the pro mini is that you only have 2 interrupts and 1 is used for the radio, leaving you 1 for your project, which is probably fine for your application.
If you used a pro micro (32U4) instead, you would have 5 interrupts, leaving 4 for your project. And I don't think I've ever seen an rfm69 board for the pro micro, so it would be a first. Just a thought.

Hi @Leonel-Epps.
My pleasure, I've gotten a lot of good ideas from the Forum, its always good to give back.

P.S.
My washing machine leak sensor alerted me to a leak about 3 weeks. I checked, and sure enough, there was a small puddle of water under the machine. The door seal was wearing and had a few tears in the bellows.

I replaced the door seal (thank you youtube videos) and all is good. The washing machine is on the upper floor in my home and could have done serious damage to the lower level if it hadn't been detected quickly.

Regards,
KevinT

HI @Henil179

I made one myself a couple of years ago, and yes, it was a fair bit of trial and error to get it working.
Of course, the gain values will be dependent on a number of factors, for example, the torque constant of your motor, the gear ratio, the mass of the robot, where your centre of gravity is located, your loop rate, and where you've located your mpu-6050.
I located my mpu-6050 over the axis at 12 o'clock near the vertical centre of my bot.

What are you control variables?
I used pitch (angle of rotation around motor axis) calculated from gx, gz and tan function.
I also used pitch rate from the gyro.

Are you using the onboard DSP of the mpu-6050 to do the calculations?
I had no luck with this, the mpu-6050 kept freezing up, bad clone I guess.

You also have to verify the direction of rotation of your motor versus your control variables.
If you have the wrong direction, it will just run away.

My gains are Kp:41, Ki:160, Kd:0.4

I started with only Kp and kept increasing the value until the system became unstable, then I backed off to a stable point.
Next, I began increasing Ki. This will bring you to steady state stability. It should balance itself when Kp & Ki.
You will likely have to reduce Kp somewhat as you move to higher Ki values, if your system becomes unstable.
Finally, I added Kd, to help it react more quickly to changes in angle.

How do you change your gains?
I have a bluetooth module on mine, to allow me to send serial commands to the robot, to set the gains and other things.

My robot's biggest problem is gear backlash. This generates acceleration noise as it vibrates backward/forward, balancing itself. This vibration can feedback on itself and cause instability (when you increase Kp too high). It looks like the robot has Parkinsons when this happens!

I'd like to update my design to use a belt/gear drive or continuous rotation servo, but I haven't had a chance to get back to it.

I hope this helps.

@ejlane Your Death star speaker sounds pretty impressive! LEDs, timer/stopwatch, impact sensor, and of course speaker & microphone, she'll be loaded. You'll have to share a few pictures. How big will it be? Which Pi fits inside it?

@CrankyCoder The code can be found on Github: Washer-Dryer-Monitor

@CrankyCoder

1. I used a JDY-31 module without the carrier board. The module operates on 3.3V and has a header with 0.1" spacing, perfect for my needs.
2. Yes, I can share the code. There's the main sketch plus 2 libraries, one for the statistics and a modified version of the debounce library which allows me to debounce a boolean variable. The leak sensor needs this or you can get a flood of leak messages.
   Where do you want me to put the code? I can put it up on Github if you like. Might be a bit much to paste here.

Regarding the rhasspy project, I hadn't heard about this, I will definitely check it out. Thanks!

@ejlane Oh, now I get your question. Text to Speech is built into the Android OS on the phone. There is a synthesis engine which runs on the phone and generates the speech. Although it likely has networked features, for example, loading different voices.
Project Alice looks quite interesting. I'll definitely be digging deeper. I see it runs on Raspberry Pi's, maybe it will run on my Ubuntu server too.

@ejlane Yes, my speakers are best described as MQTT Text to Speech output devices. Basically, I wrote a small application which runs on a phone using MIT App Inventor. It subscribes to the Speak topic on my local MQTT broker. Whenever someone publishes to the Speak topic, it converts the text to speech. I have quite a few automations in Home Assistant which publish to Speak. I have 3 old phones set up as speakers around my house.

Regarding AI smart speakers, there is a lot of new stuff out there, with the release of tinyML.
From what I've read, the easiest type of speech recognition is "Keyword spotting" - see Edge Impulse
The next level is "Speech to Intent" - see Wio Terminal TinyML course
And the highest level is Large-vocabulary continuous speech recognition.

@ejlane So far, I have a leak sensor under my clothes washer and hot water heater. I got the idea after my dish washer began leaking and damaged my kitchen cabinets. Dish washer is next...
I should clarify regarding the smart speaker. They really are MQTT text to speech speakers built from old cell phones I had laying around the house. I wrote an app in MIT app inventor. It could be expanded to play mp3 files of course and displaying images too.
I would like to create a smart speaker using Jetson Nano, but I haven't gotten around to it yet. Smart speakers might be an idea for a new thread. I haven't looked into it very deeply and could use some ideas too.

@mfalkvidd Thanks. Yes those are spacers that snap on to the wires. I 3d printed them as well as the enclosure.

Hi everyone,
I'd like to share my latest project.
I've built up a node which monitors our washing machine for leaks and monitors our dryer for operation.
The node uses an arduino pro mini with an RFM69 radio. It runs continuously on a 5V wall wart supply regulated down to 3.3V.


The leak sensor is a classic probe type with 2 parallel conductors and a signal conditioner board (transistor based) which generates an analog voltage to represent the leak signal. When the signal exceeds the programmed threshold the leak is reported (using a binary sensor).


I used 14 gage solid copper wire to make the probe.

Dryer operation is sensed using an MPU-6050 accelerometer. I use the absolute value of the vibration signal and pass it through a moving average filter to get a steady signal.
The node is mounted to the dryer using magnets glued to the enclosure.

I also threw in a JDY-31 bluetooth module for serial monitoring/debug. So cheap and easy, why not?!

The vibration threshold can be set in Home Assistant, to allow for easy fine tuning.

I also added running statistics, updated every minute, of min (var1), max (var2) and average (var3) vibration levels to make it easier to set the threshold.

And to keep the wife happy , I have our home made smart speakers announce when the dryer is done.

@mfalkvidd Good point. I don't know too much about the library, but if that's all it takes, I'll definitely try it.

@zboblamont Thanks for the link, I wasn't finding anything with "sleepy dog", never thought to remove the space. That should help too. I just have to figure out what to do with the RFM radio, if it has a power down mode, etc. Keep us posted on the Sensebender trials. Thx.

@zboblamont When I search the MySensors library (2.3.2) for sleep(), I find the return value "MY_SLEEP_NOT_POSSIBLE" for the sleep functions. file: MyHwSAMD.cpp

int8_t hwSleep(uint32_t ms)
{
	// TODO: Not supported!
	(void)ms;
	return MY_SLEEP_NOT_POSSIBLE;
}

int8_t hwSleep(uint8_t interrupt, uint8_t mode, uint32_t ms)
{
	// TODO: Not supported!
	(void)interrupt;
	(void)mode;
	(void)ms;
	return MY_SLEEP_NOT_POSSIBLE;
}

But, as you mentioned , it looks like @Alpoy has implemented his own sleep code.
Feather m0 (SAMD) sleep and interrupt
I'll have to try it and see if it will work for me.
Thanks.

Thanks.
The motion sensor is used to turn on the lights in the garage via a Sonoff mini.
Also, I've had the garage door randomly open by itself (power glitches?) a few times over the years. So I'm adding an automation to close the door if no motion is present and it is after midnight.

Finished my Garage Door Node.
It has open/close magnetic reed switch sensors, a DS18B20 temperature sensor, a PIR motion sensor and a bjt to trigger the door to open/close/stop.

20210612_201851[1].jpg

Hi all,

I've been looking for an mcu that would provide me with more interrupts for my RFM69 nodes and support sleep functions.
I've checked out SAMD and STM32 and they don't appear to support sleep. "MY_SLEEP_NOT_POSSIBLE"

Is there any plans to add sleep functionality for these mcu's?

Other options?

Thanks,

KevinT

@mfalkvidd Thanks, that's exactly what I need. I wasn't sure how to retrieve the values at the gateway.
Just wondering how the receive works. Is it called every time the gateway receives data from a node, after the node processes the message?

Thanks again,
KevinT

Hi,

I'm running a mysensors network using RFM69 radios and I am wondering if it is possible to have the gateway report (as sensors) all the attached node's rf power levels?

I have played with the rf reporting and I currently have a couple of nodes reporting their levels. I configured the 'sensors' as S_LIGHT_LEVEL since I report the 0-100% transmit level. I couldn't find a sensor specific to rf power.

Just thought it would be easier to have the gateway report the levels since the measurements are coming from the gateway in the first place.

Thanks,

Kevin

I know this thread is old, but it might help others in future searches.

I simply deleted the child I no longer used from the persistence file, saved it and restarted Home Assistant.
The child was gone.
If you want to change a child to a new sensor this also works.
After restarting Home Assistant, power up the node and the child will present itself and update the persistence file.

@scalz
That was going to be my next question, the expected range/power for RFM69W, if they are good, reasonable radios.
I also noticed in the forums a lot of complaints about bad NRF24L01 clones. It seems that RFM radios are a better choice?

@scalz
This is my first attempt at using the lower power PA0. I am getting an RSSI of -75 with the radios about 5m apart and the radio using 10 dBm to achieve this. Quite disappointing. I was expecting the transmit power to be much lower, since in High Power mode I was getting an RSSI of -45 with transmit power of -2 dBm.
I thought that perhaps the radio was reporting the wrong transmit power, or that the library was not interpreting it correctly. I expected results similar to the data sheet.

But you say this is a common problem!
I was planning on standardising on the high power radio for all my nodes, but now I see I will have to switch to the RFM69W for many of them.

Thanks very much for taking the time to bring me up to speed, its greatly appreciated.

Hi @scalz,
I don't know, I've tried it, it worked for me.
Just to be clear, I'm still using #define MY_RADIO_RFM69
What in the library would stop it?

Documenting what I've found in the library code for the community.
When using #define MY_IS_RFM69HW:
The driver enables PA1 and PA2 and disables PA0 power amps. It automatically selects the right combination of PA1 and PA2 to achieve the target power level.
Power range is -2 to +20 dBm

When NOT using #define MY_IS_RFM69HW:
Then only PA0 is enabled.
PA0 is identical between the RFM69W and RFM69HW.
Power range is -18 to +13 dBm
Basically, your RFM69HW operates as an RFM69W.

Also, when using the new RFM69 driver, ATC mode is on by default, unless you explicitly turn it off using macro #define MY_RFM69_ATC_MODE_DISABLED
The default ATC target RSSI level is -80 dBm which you can change using #define MY_RFM69_ATC_TARGET_RSSI_DBM

Cheers

I've more information to share.

Seems I was running out of memory, when I turned off debug, which freed up some room, I started to get more reasonable results.

Uplink Qlty: 0, Xmit Level (dBm): -2, Xmit Level (%): 0
Xmit RSSI: -45, Recv RSSI: -39

Wondering if this is as low as it can go?

Looking at the datasheet,
PA1 and PA2 combined on pin PA_BOOST: +2 to +17 dBm
and
PA1+PA2 on PA_BOOST with high output power +20dBm settings (see 3.3.7): +5 to +20 dBm

I don't know what power level is selected when we enable #define MY_IS_RFM69HW

Can we simply run it as a low power RFM69 by commenting out the #define?

Hi,
I'm hoping someone can help me with ATC mode on my RFM69HW/Arduino Pro Mini nodes.
I've enabled it per the example sketch RFM69_RFM95_ATC_SignalReport.ino.

I've updated the node & gateway to use the new RFM69 driver.

It doesn't seem to adjust the transmit power on my node and I get a TSF error as well.
A couple example debug outputs:

BME280 - Sending the new humidity to the gateway.
55791 TSF:MSG:SEND,4-4-0-0,s=1,c=1,t=1,pt=7,l=5,sg=0,ft=0,st=OK:53.11
Uplink Qlty: 0, Xmit Level (dBm): 107, Xmit Level (%): 140
Xmit RSSI: -46, Recv RSSI: -54, Xmit SNR: -256, Recv SNR: -256
55805 TSF:MSG:READ,92-1-4,s=2,c=1,t=4,pt=0,l=6,sg=0:102.05
55816 !TSF:MSG:LEN=26,EXP=13
State: ST_SLEEP

Uplink Qlty: 0, Xmit Level (dBm): 11, Xmit Level (%): 108
Xmit RSSI: -46, Recv RSSI: -53, Xmit SNR: -256, Recv SNR: -256
56082 TSF:MSG:READ,92-2-4,s=2,c=1,t=4,pt=0,l=6,sg=0:102.05
56094 !TSF:MSG:LEN=32,EXP=13
56096 TSF:MSG:READ,92-2-4,s=2,c=1,t=4,pt=0,l=6,sg=0:102.05
56102 !TSF:MSG:LEN=26,EXP=13
State: ST_SLEEP

You can see that the Xmit levels don't make sense.
The Xmit RSSI should be moving towards -70 dBm but never really changes.

Here's the macros in the node's code:

// if you uncomment this, you can get test and debug updates about everything the sensor is doing by using the serial monitor tool.
#define MY_DEBUG 

// Enable and select radio type attached
//#define MY_RADIO_RF24                            // A 2.4Ghz transmitter and receiver, often used with MySensors.
// #define MY_RF24_PA_LEVEL RF24_PA_MIN              // This sets a low-power mode for the radio. Useful if you use the version with the bigger antenna, but don't want to power that from a separate power source. It can also fix problems with fake Chinese versions of the radio.
#define MY_RADIO_RFM69                        // possible 434, 868, 915Mhz transmitter and reveiver.
#define MY_RFM69_NEW_DRIVER                   // ATC on RFM69 works only with the new driver (not compatible with old=default driver)
#define MY_IS_RFM69HW                         // high power version of radio
#define MY_RFM69_FREQUENCY  RFM69_915MHZ
#define MY_RFM69_ATC_TARGET_RSSI_DBM (-70)    // target RSSI -70dBm
#define MY_RFM69_MAX_POWER_LEVEL_DBM 10       // max. TX power 10dBm = 10mW

// Do you want this sensor to also be a repeater?
// #define MY_REPEATER_FEATURE                    // Just remove the two slashes at the beginning of this line to also enable this sensor to act as a repeater for other sensors. If this node is on battery power, you probably shouldn't enable this.

// Are you using this sensor on battery power?
#define BATTERY_POWERED

// Would you like to report humidity?
#define REPORT_HUMIDITY

// LIBRARIES
#include <SPI.h>                                  // A communication backbone, the Serial Peripheral Interface.
#include <MySensors.h>                            // The MySensors library. Hurray!
#include <Wire.h>                                 // Enables the Wire communication protocol.
#include <BME280_MOD-1022.h>                      // Bosch BME280 Embedded Adventures MOD-1022 weather multi-sensor Arduino code, written originally by Embedded Adventures. https://github.com/embeddedadventures/BME280

and later, in the loop()

#ifdef REPORT_HUMIDITY
      // Send humidity
      if (COMPARE_HUM == 1 && fabs(humidity - lastHumidity) < humThreshold) { // is the humidity difference bigger than the threshold?
//        Serial.print(humidity - lastHumidity);
//        Serial.println("- BME280 - Humidity difference too small, so not sending the new measurement to the gateway.");
      } else {
        Serial.println("BME280 - Sending the new humidity to the gateway.");
        send(humidityMsg.set(humidity, 2));
        lastHumidity = humidity; // Save new humidity to be able to compare in the next round.
      }
#endif
      // Send pressure
      if (COMPARE_PRES == 1 && fabs(pressure - lastPressure) < presThreshold) { // is the pressure difference bigger than the threshold?
//        Serial.print(pressure - lastPressure);
//        Serial.println("- BME280 - Pressure difference too small, so not sending the new measurement to the gateway.");
      } else {
        Serial.println("BME280 - Sending the new pressure to the gateway.");
        send(pressureMsg.set(pressure, 2));
        lastPressure = pressure; // Save new pressure to be able to compare in the next round.
      }

      ReportRfPower();
      state = ST_SLEEP;
      break;

and the report of ATC values:

void ReportRfPower()
{
  Serial.print("Uplink Qlty: ");  Serial.print(transportGetSignalReport(SR_UPLINK_QUALITY));
  Serial.print(", Xmit Level (dBm): ");  Serial.print(transportGetSignalReport(SR_TX_POWER_LEVEL));
  Serial.print(", Xmit Level (%): ");  Serial.println(transportGetSignalReport(SR_TX_POWER_PERCENT));
        
  Serial.print("Xmit RSSI: ");  Serial.print(transportGetSignalReport(SR_TX_RSSI));
  Serial.print(", Recv RSSI: ");  Serial.print(transportGetSignalReport(SR_RX_RSSI));
  Serial.print(", Xmit SNR: ");  Serial.print(transportGetSignalReport(SR_TX_SNR));
  Serial.print(", Recv SNR: ");  Serial.println(transportGetSignalReport(SR_RX_SNR));
}

Any ideas?

Hi electrik,
Yes, my nodes send the sketch name within the presentation function.
As for the gateway, I have not set up a sketch name, the example I found did not implement this, so I didn't think it
was necessary?

I manually named the gateway node in the configuration.yaml file, and the "missing sketch name" message no longer appears in the log. I guess, I'll add an entry for node 0 (controller) as well .

I'm still getting the "USB0 not ready after 15.0 secs" at startup, but all seems to work regardless.

I connected the gateway to my pc using mycontroller, it all works fine. Logs look normal.

Here is the code for one of my nodes, a temperature node with Arduino mini & RFM69 radio, running on battery.

// Enable debug prints to serial monitor
#define MY_DEBUG 
#define MY_BAUD_RATE 38400

// Enable and select radio type attached
//#define MY_RADIO_RF24
#define MY_RADIO_RFM69
#define MY_IS_RFM69HW
#define MY_RFM69_FREQUENCY  RFM69_915MHZ

#include <MySensors.h>  
#include <DallasTemperature.h>
#include <OneWire.h>

#define COMPARE_TEMP 0 // Send temperature only if changed? 1 = Yes 0 = No

#define ONE_WIRE_BUS 8 // Pin where dallas sensor is connected 

#define CHILD_ID_TEMP 0
#define CHILD_ID_BATT 1

// function protos
void ReadBat(double& b, uint8_t& bPct);

unsigned long SLEEP_TIME = 300000;    // Sleep time between reads (5min) (in milliseconds)
const int BAT_V = A0;                 // battery voltage, AnaIn 0

OneWire oneWire(ONE_WIRE_BUS);        // Setup a oneWire instance to communicate with any OneWire devices (not just Maxim/Dallas temperature ICs)
DallasTemperature sensors(&oneWire);  // Pass the oneWire reference to Dallas Temperature. 

float lastTemperature;
double bat, lastBat=0.0;
uint8_t batPct;
int numSensors=0;
bool receivedConfig = false;
bool metric = true;
bool initialValuesSent = false;
bool initialValTempSent = false;
bool initialValBatSent = false;

// Initialize message objects
MyMessage msg(CHILD_ID_TEMP, V_TEMP);
MyMessage msgBatt(CHILD_ID_BATT, V_VOLTAGE);

void before()
{
  // Startup up the OneWire library
  sensors.begin();
}

void setup()  
{ 
  sensors.setWaitForConversion(false);
  // requestTemperatures() will not block current thread
  Serial.print("Found ");
  Serial.print(sensors.getDeviceCount(), DEC);
  Serial.println(" temperature devices.");
  sensors.requestTemperatures();
}

void presentation() {
  Serial.println("Sending presentation");
  // Send the sketch version information to the gateway and Controller
  sendSketchInfo("Temperature Sensor", "1.2");
  // Present all sensors to controller
  present(CHILD_ID_TEMP, S_TEMP, "Bed room Temperature");
  present(CHILD_ID_BATT, S_MULTIMETER, "Bed room node Voltage");
}

void loop()     
{     
  int16_t conversionTime = 0;
  float temperature = 0;
  
  if (!initialValuesSent) {
    Serial.println("Sending initial value");
    // Read in the battery voltage
    ReadBat(bat, batPct);
    // get temperature conversion time
    conversionTime = sensors.millisToWaitForConversion(sensors.getResolution());
    wait(conversionTime);
    // Fetch temperature
    temperature = sensors.getTempCByIndex(0);
    // send the temperature reading
    // set(float value, uint8_t decimals)
    send(msg.set(temperature, 2));
    Serial.println("Requesting initial Temp value from controller");
    request(CHILD_ID_TEMP, V_TEMP);
    wait(2000, C_SET, V_TEMP);
    // send bat voltage
    send(msgBatt.set(bat, 2));
    Serial.println("Requesting initial Batt value from controller");
    request(CHILD_ID_BATT, V_VOLTAGE);
    wait(2000, C_SET, V_VOLTAGE);
  }
//  {
  else {
    // Fetch temperatures from Dallas sensors (non-blocking)
    sensors.requestTemperatures();
    // Read in the battery voltage
    ReadBat(bat, batPct);
  
    // query conversion time and sleep until conversion completed
    conversionTime = sensors.millisToWaitForConversion(sensors.getResolution());
    
    // sleep() call can be replaced by wait() call if node need to process incoming messages (or if node is repeater)
    sleep(conversionTime);
  
    // Read temperature and send to controller 
    // Fetch temperature
    temperature = sensors.getTempCByIndex(0);
    Serial.println("temperature: ");
    Serial.println(temperature);
  
    // Only send data if temperature has changed and no error
    #if COMPARE_TEMP == 1
    if (lastTemperature != temperature && temperature != -127.00 && temperature != 85.00) {
    #else
    if (temperature != -127.00 && temperature != 85.00) {
    #endif
      // Send in the new temperature
      // set(float value, uint8_t decimals)
      send(msg.set(temperature, 2));
      // Save new temperatures for next compare
      lastTemperature=temperature;
    }
    // Send in the new battery level
    sendBatteryLevel(batPct);
    send(msgBatt.set(bat, 2));
    // Save the battery level for next compare
    lastBat = bat;
    Serial.println("Sleep...");
    sleep(SLEEP_TIME);
  }
}

void receive(const MyMessage &message) {
  if (message.isAck()) {
     Serial.println("This is an ack from gateway");
  }

  if (message.type == V_TEMP) {
    if (!initialValTempSent) {
      Serial.println("Received initial temp value from controller");
      initialValTempSent = true;
    }
  }
  else if (message.type == V_VOLTAGE) {
    if (!initialValBatSent) {
      Serial.println("Received initial bat value from controller");
      initialValBatSent = true;
    }
  }
  if (initialValTempSent && initialValBatSent)
    initialValuesSent = true;
}

// b - battery voltage
// bPct - battery percent
void ReadBat(double& b, uint8_t& bPct)
{
  long sumBat=0;
  int i;

  // take average over 64 readings
  for (i = 0; i < 64; ++i) {
    // read & sum battery voltage
    sumBat += analogRead(BAT_V);
  }
  sumBat = sumBat >> 6;      // shift 6 -> divide by 64
  b = sumBat*3.3/1023.0;
  bPct = (uint8_t)(sumBat*100.0/1023.0);
}

Here is the serial gateway sketch:

#include <SoftwareSerial.h>
SoftwareSerial softSerial(8, 9); // RX, TX

// Enable debug prints to serial monitor
#define MY_DEBUG
#define MY_DEBUGDEVICE softSerial
// You also need to create softSerial in setup()

// Enable and select radio type attached
//#define MY_RADIO_RF24
//#define MY_RADIO_NRF5_ESB
//#define MY_RADIO_RFM95
#define MY_RADIO_RFM69
#define MY_IS_RFM69HW
#define MY_RFM69_FREQUENCY  RFM69_915MHZ


// Set LOW transmit power level as default, if you have an amplified NRF-module and
// power your radio separately with a good regulator you can turn up PA level.
//#define MY_RF24_PA_LEVEL RF24_PA_LOW

// Enable serial gateway
#define MY_GATEWAY_SERIAL

// Define a lower baud rate for Arduinos running on 8 MHz (Arduino Pro Mini 3.3V & SenseBender)
#if F_CPU == 8000000L
#define MY_BAUD_RATE 38400
#endif

// Enable inclusion mode
#define MY_INCLUSION_MODE_FEATURE
// Enable Inclusion mode button on gateway
//#define MY_INCLUSION_BUTTON_FEATURE

// Inverses behavior of inclusion button (if using external pullup)
//#define MY_INCLUSION_BUTTON_EXTERNAL_PULLUP

// Set inclusion mode duration (in seconds)
#define MY_INCLUSION_MODE_DURATION 60
// Digital pin used for inclusion mode button
//#define MY_INCLUSION_MODE_BUTTON_PIN  3

// Set blinking period
#define MY_DEFAULT_LED_BLINK_PERIOD 300

// Inverses the behavior of leds
//#define MY_WITH_LEDS_BLINKING_INVERSE

// Flash leds on rx/tx/err
// Uncomment to override default HW configurations
//#define MY_DEFAULT_ERR_LED_PIN 4  // Error led pin
//#define MY_DEFAULT_RX_LED_PIN  6  // Receive led pin
//#define MY_DEFAULT_TX_LED_PIN  5  // the PCB, on board LED

#include <MySensors.h>

void setup()
{
  softSerial.begin(38400);
}

void presentation()
{
	// Present locally attached sensors
}

void loop()
{
	// Send locally attached sensor data here
}

Thanks.

I was missing 2 things, the presentation of S_MULTIMETER, the battery voltage I also send out, and the initial value send in the main loop. (Funny, I had read these myself but ignored them thinking I had a timeout problem.)

For the initial value send, I have 2 sensors, can I just read back the value of the last sensor sent, or do I have to verify all of them?
(I am assuming this is just a step to ensure the controller is ready before continuing?)

Also, though everything now works, I still get the timeout (not ready) on the serial port. Is this normal?

Also, 2 strange warnings, node 0 (controller?) and node 1 (gateway) missing sketch names?

2020-04-18 09:57:00 DEBUG (SyncWorker_16) [mysensors.persistence] Loading sensors from persistence file /config/mysensors1.pickle
2020-04-18 09:57:00 DEBUG (SyncWorker_6) [mysensors.persistence] Saving sensors to persistence file /config/mysensors1.pickle
**2020-04-18 09:57:00 DEBUG (MainThread) [homeassistant.components.mysensors.helpers] Node 1 is missing sketch name
2020-04-18 09:57:00 DEBUG (MainThread) [homeassistant.components.mysensors.helpers] Node 0 is missing sketch name**
2020-04-18 09:57:00 INFO (MainThread) [homeassistant.components.mysensors] Adding new devices: [<Entity Temperature Sensor 2 1: None>, <Entity Temperature Sensor 2 0: None>]
2020-04-18 09:57:00 DEBUG (MainThread) [homeassistant.components.mysensors.device] Entity update: Temperature Sensor 2 1: value_type 38, value = 2.85
2020-04-18 09:57:01 DEBUG (MainThread) [homeassistant.components.mysensors.device] Entity update: Temperature Sensor 2 0: value_type 0, value = 21.44
2020-04-18 09:57:01 INFO (MainThread) [mysensors.gateway_serial] Trying to connect to /dev/ttyUSB0
2020-04-18 09:57:01 INFO (MainThread) [mysensors] Connected to Serial<id=0x6b041470, open=True>(port='/dev/ttyUSB0', baudrate=38400, bytesize=8, parity='N', stopbits=1, timeout=0, xonxoff=False, rtscts=False, dsrdtr=False)
2020-04-18 09:57:03 DEBUG (MainThread) [mysensors] Receiving 2;0;1;0;0;21.44
2020-04-18 09:57:03 DEBUG (MainThread) [homeassistant.components.mysensors.gateway] Node update: node 2 child 0
2020-04-18 09:57:03 DEBUG (MainThread) [homeassistant.components.mysensors.device] Entity update: Temperature Sensor 2 0: value_type 0, value = 21.44
2020-04-18 09:57:10 DEBUG (SyncWorker_11) [mysensors.persistence] Saving sensors to persistence file /config/mysensors1.pickle
**2020-04-18 09:57:16 WARNING (MainThread) [homeassistant.components.mysensors.gateway] Gateway /dev/ttyUSB0 not ready after 15.0 secs so continuing with setup**
2020-04-18 09:57:35 DEBUG (MainThread) [mysensors] Receiving 2;0;1;0;0;21.44
2020-04-18 09:57:35 DEBUG (MainThread) [homeassistant.components.mysensors.gateway] Node update: node 2 child 0
2020-04-18 09:57:35 DEBUG (MainThread) [homeassistant.components.mysensors.device] Entity update: Temperature Sensor 2 0: value_type 0, value = 21.44
2020-04-18 09:57:40 DEBUG (SyncWorker_2) [mysensors.persistence] Saving sensors to persistence file /config/mysensors1.pickle

I'm getting WARNING: Gateway /dev/ttyUSB0 not ready after 15.0 secs
But serial data is getting through, as it shows up later in the log.
2020-04-17 16:05:35 DEBUG (MainThread) [mysensors] Receiving 2;255;3;0;0;86
2020-04-17 16:05:35 DEBUG (MainThread) [homeassistant.components.mysensors.gateway] Node update: node 2 child 255
2020-04-17 16:05:35 DEBUG (MainThread) [mysensors] Receiving 2;1;1;0;38;2.84
2020-04-17 16:05:35 WARNING (MainThread) [mysensors] Child 1 is unknown

Any idea why the gateway isn't getting set up correctly?

Gateway is an Arduino mini, baudrate 38400. Using standard gateway sketch.
Home Assistant is latest version, 32bit, running on PI 3B+.