Posts made by evb

Correct, me too. I've set in my profile, weekly digest, so it's only weekly, but always twice.
I observe this behavior already for months.
@mfalkvidd, do you have an idea why?

We are approximately 2 years later, a little follow-up

I had already noticed for a week of so that my 3 oldest sensors (including my prototype sensor) were no longer sending their status consistently. After checking the reported battery levels of the sensors I saw that there were around 50%, so that was normal... (50 % of 3V is 1.5V , below the BOD of 1.8V)

So the sensors with this design worked for about 20 months on 2 normal AA batteries of 1.5 V, not bad

Hi @Merlotmaker,

If you want more reactions from members, you should provide more information.

• what for sensor do you have, because you are speaking about BMP280 and BME280
• the lib you are referring to is a specific one for the https://www.sparkfun.com/products/13676
• how did you connect your sensor to the UNO?
• did you follow this guide already? https://learn.sparkfun.com/tutorials/sparkfun-bme280-breakout-hookup-guide

@Mati_Smart, if the messages from the sensor are arriving in domoticz, it must be some configuration in domoticz itself.
Can't help you here, I don't know domoticz.
Did you search already on the domoticz forum?

Hi @Mati_Smart, I didn't say that you can't use the pins D20 and D21.
But for now they are not working in your current setup, so try first to modify your sketch to include only the code necessary to use digital pins as input. Nothing more, nothing less.

Do you have experience with arduino hardware and arduino programming?
There are plenty of arduino sketches out there in the wild, but without knowledge how they work, makes it very difficult to find solutions if they don't work on your hardware setup.

For example you can try first to understand this very simple mysensors sketch : https://www.mysensors.org/build/binary
Even simpler, try an arduino sketch without mysensors code https://www.youtube.com/watch?v=YWY_Is0L7fE
Try to understand the basics of Arduino programming and hardware before getting to more complicated hardware and sketches.

Hi @Mati_Smart,
Why are you using the relay actuator sketch if you want to read inputs?

First rule in debugging things, is to narrow down the problem.
Make your sketch to contain only the things you need.
Verify if your sketch is meant to work with the hardware you are using.
If the sketch is written originally for a Arduino Uno and you are using it on a Arduino Mega 2560, there is a chance that the used port numbers are not correct.
For example I see that on a mega, the D20 and D21 pins are also pins used for SDA and SCL. Try to use first the normal digital pins, like D2, D3, ...

Hi @electrik,

Maybe you can answer my question: What is the height of the two stacked together?
Like said, I'm very limited in height, so I did not take the risk to order this board (yet)...

Hi @chey, no, with the pro minis and MySensors lib I couldn't get less.
Didn't measure with yet another multimeter though...

My battery sensors are working now for about a year and the battery levels are between 65% and 70%.
The sensor furthest from the gateway is at 65% and the 3 others at 70%.
Not bad I think.
https://forum.mysensors.org/topic/11499/checking-mechanical-locked-doors-by-a-battery-based-windows-door-sensor-node

Hi @Prohi, can you provide more information about your heating system?

When searching about AirMax on the internet, I found this: https://www.airmaxhvac.com/ and this https://airmaxsc.com/ and this https://airmaxop.com/ and ...
Is your heating system an hvac based system?
With remote controls for each room?

I'm afraid you're not going to get many answers to your question if you provide not more information...

• type of heat pump, manufacturer
• what are the current possibilities of controlling this heat pump
• photo's
• electric schema's
• ...

Try to give as much as possible (technical) information...

Hi @DanielKr,

Great that it works now!

Very strange that a 12V/1A power supply cannot deliver enough power. It should be enough! There must be something else. I use 9V/1A stabilized power supplies all the time for non battery powered sensors/gateways.
The used USB power supply can deliver how much current?

The little capacitor of 0.1uF is a so called "High Frequency killer" cap. It smooth out the high frequency noise in the circuit.
The 'big' 47 uF acts as buffer and ensures that the radio will get enough power when it requires it.
If you want read more about it, for example : https://www.spsvit.com/post/the-0-1uf-filter-capacitor-a-tradition-or-a-wise-choice

The range problem is a difficult one. There are many reasons why the range can be poor.
Which antenna are you using? Like me on the photo? Is it connected like on the photo?
Putting the receiving antenna and sending antenna in the same vertical direction can help to extend the range.
Search on this forum for more tips to extend the range.
Even me I connected an commercial bigger antenna to my gateway to extend the range trough walls and concrete floors.

Hi @DanielKr,

When you enable the new driver #define MY_RFM69_NEW_DRIVER in your mqtt gateway, does your sending node sensor uses also the new driver? Or is it still using the old RFM69 driver?

I'm not for 100% sure, but I think that each mysensor node must use the same RFM69 driver.
In this case your sending node and the mqtt gateway must use the new driver.

Can you test?

@canyouhearmenow I didn't see my version of the sketch, but then I saw that the column sk_version was commented out.
I added again this missing column. I don't use revision, only version.

I saw also that the api_version of my repeaters were not reported. I added support for this to the code.

The sqlite db is filling up with all these mqtt messages.
Do you clean up this after some time?

Great work, thanks for putting it online

@canyouhearmenow I've adapted your script to support authentication and SSL connection. See my pull request

Meanwhile, I see in your printscreens, API, version, battery changed, etc.
Is this data filled in via your sketches? Are the nodes sending this information? Via the presentation?

@mutantx, sorry for the late reply, but I was on holidays

I've no experience with this sketch code, nor the hardware build of this mp3 player.
Try to contact the author of this player or you can check the general documentation about the use of V_VARx / S_CUSTOM : https://www.mysensors.org/download/serial_api_20

Try to break up things in little pieces when accumulating knowledge about mysensors.
Big complicated sketches can be overwhelming.
I start always, when troubleshouting, with the cleanest version of the script, with minimum code required for operation. And then I build it up.

@Ispandy, let resume some things because I'm lost

You copied the sketch code from node 3 (= correctly running node with cardscans and remote control from openhab) to node 50 and you adapted the node id.
This same sketch on node 50 is running correctly with cardscans but not with openhab? Correct?

If above is correct: somewhere your openhab configuration for this node 50 is not correct. You say that node 50 is never receiving the openhab command, so there is a problem with your openhab configuration for node 50.

@Ispandy what happens if you download the same sketch from the working node 3 tot your new node 50?
Adapt of course the node-id!

If it works we can exclude a hardware problem, then it must be a software problem.
In that last case, we can check your sketch more deeply.

@cvdenzen I don't have experience with a Raspberry Pi as MQTT gateway, but your last remark about the slash is maybe a path to debug...

From the docs for a Arduino MQTT gateway:
The topic is build like this: MY_MQTT_PUBLISH_TOPIC_PREFIX/FROM-NODE-ID/SENSOR-ID/CMD-TYPE/ACK-FLAG/SUB-TYPE
Read more about the serial protocol here. An example topic for data received from your gateway could look like this:

mygateway1-out/2/1/1/0/49

If you want to send data to your sensors use MY_MQTT_SUBSCRIBE_TOPIC_PREFIX defined in your sketch. Should be looking like this (using default sketch):

mygateway1-in/2/1/1/0/49

Can you try to change your mqtt topic build?

@Ispandy are you now speaking about 2 nodes?

In that sketch above the node doesn't receive message from openhab
Did you add serial prints to be sure you don't receive anything. May you receive messages but not of the type V_LOCK_STATUS.

You should explain more in detail how your setup is done, because for me it isn't clear

@mfalkvidd, should this not be better receive it's own topic?

@Ispandy, does your node receives the message from openhab?
Change the code in the receive method to be able to serial print debug messages. Maybe openhab is not using the correction message type...

@Zwer2k , what do you mean by the 'current development branch'?
The production version 2.3.2? or the latest code from the dev branch?

If you revert back to your original version of the code, your gateway is working again?

@TheStaticTurtle, did you try this several times? Wiping out the EEPROM and reflashing the sketch?
Did the node connects correctly each time after this wiping cycle?

If yes, I would suspect the pro mini to have a problem with his EEPROM...
Do you have a spare pro mini? Try with another pro mini.
If not, you can post your sketch here so we can look at it. Try also to minimize the sketch content to debug this problem.

Your logs are indicating that the pro mini is sending a parent request, the gateways responds to it, but the node doesn't see the gateway response...

@mutantx follow the other link in your link : https://www.openhardware.io/view/373/MP3-player-with-RGB-signal-LED-optionally-battery-powered and you will find the schematic.

@cvdenzen In case of troubleshooting, try to comment out the maximum of code, only the bare minimum of code should remain active.
Go back to the original code of the dimmer : https://www.mysensors.org/build/dimmer and test first if this sketch receives the messages.

I suppose you are using a arduino pro mini when you speak of a newbie board. So effectively it is not easy to connect a laptop to the serial output. I don't think the arduino will reset when connecting, but it's not convenient.

So to detect if it is the relayboard, can you deconnect it from the newbie board and let run the node like this.
If it works now for some time, we are sure it is the relayboard somehow influencing the arduino.
If it still freeze, it is not the relayboard and we must continue to debug...

@CrankyCoder This could have several reasons...
To debug this, you should activate the mysensors debug statement. Let the node run and at the moment you see no connection anymore, connect a laptop/computer to the node via the serial connection and see what the node is doing.
It could be that the node is frozen.
You are talking about a 2 relay node. How this relay board is connected to the newbie board? A selfmade relay board or a bought one? What are you switching with these relays? External systems can have an 'electronic' influence on the arduino causing a malfunction...

@p359 I have republished it and now I get the 'thing', no 404 anymore.
Can you try again?

@Yveaux Correct, the 1Mhz will hardly increase battery life. But the node will continue to work till 1.8V in a safe operating area. I'm referring to your own posted diagrams
https://forum.mysensors.org/topic/10952/battery-pro-mini-1mhz-vs-booster/12

But yes, good advice to stay with the standards, certainly if you are new to MySensor

@DenisJ Yes, I did read also this comment, but wanting to go as low as possible with the batteries voltage, I took my chance and constructed now 3 nodes running on 1MHz internal with MySensors 2.3.2, with the idea, if it don't work, I reprogram with the minicore bootloader, the pro minis at 8 MHz. You don't loose money in trying it out

Today, after 6 months for the oldest node, they are still working without one freezing scenario...
You must just pay attention that the BME280 sensor can work at such low µp frequencies!
Look at the datasheet of this sensor.

@DenisJ I'm went the same way as @Yveaux, without booster, see my adventures at https://forum.mysensors.org/topic/11499/checking-mechanical-locked-doors-by-a-battery-based-windows-door-sensor-node
The oldest sensor is now running for 6 months and the battery level is at 89%

Just pay attention at the lowest possible voltage for all your components to operate on a stable way.
If the 328 can go as low as 1.8V, but the temp sensor stops working at 2.2V, then 2.2V will be the lowest voltage that you can go!

@petter, When I read your reply, I notice that you are at home in this security matter.
I think many readers, even on this technical forum, are already dropping out when reading so many jargon terms

As I said, how far do you want to go for your home security?
Already, with my 'simple' setup (see above), I am the only person at home who can fix it if there are 'internet' problems for the other family members.
Once everything is set up, there is the regular maintenance in the form of updates. If updates have breaking changes, then there is extra work involved to reconfigure everything, etc.

In these covid times I had to face the facts, what if I drop out, what will my family members do?
I have several colleagues who also have security measures set up at home and are also SPOF or Single Point Of Failure....
I have also thought about it for my MySensors network.
Actually, that is quite a complicated setup for an outsider: sensors connect to a gateway, then, in my case, an MQTT server and then a home controller (Home Assistant), all running in VMs on the NAS.
This is also where I am the SPOF....
And the family members are already starting to rely on Home Assistant. The kids have named it Lexa

So my advice, provide basic security, but don't overcomplicate it....

@NeverDie my setup consists of the mandatory modem/router from my internet provider with a Zywall 110 behind it and then a managed NETGEAR switch. The provider's modem/router acts only as a conduit.

All my wifi enabled IOT devices like the heating, the energy Smappee, the sonoff modified ESPHome switches, etc are connected via a wifi access point to the specific IOT VLAN.
The MQTT VM server for the MySensors environment is also connected to the same VLAN.

Specific rules in the Zywall are permitting internet access for specific IP's on the VLAN. For example the heating, Smappee, the rituals dispenser, ... have internet access because they are cloud based vendor applications.

The controller HomeAssistant is running in the normal LAN and has a specific firewall rule to allow access to the VLAN.
Another rule is allowing only my desktop computer to access the VLAN for admin tasks like updating devices, etc

The question is all about how far you want to go in protecting your network.
There are still weak points in my setup. You can say that each firewall rule is a potential weak point...
For example the smartTV and the Bose Touch speakers are in the normal LAN because I'm playing video and music from my NAS. But they are also IOT devices...
Because I have touch screens with the home assistant (HA) GUI, the home assistant sits in the normal LAN.
I want also be able to consult HA on my smartphone, etc.

It's like securing your home, make it more secure than your neighbor and they will give up and visit him

@Gilles-BILLARD Using the lowpower lib and mysensors lib together will probably give conflicts, so you should avoid it. MySensors lib implements the same low power tricks.

When doing the latest test sketch, are you doing this also with a bare pro-mini 3.3V?
So not connected to anything, no radio, no sensor?
Try the same latest sketch, but set everything inside the loop() in comment except the sleep line.

@Leon your node is sending a request to find a parent, in this case your gateway, but your gateway is not responding.
Without more information it will be impossible to help you further...

The sketch of the arduino can help, the config file of the Pi gateway, activating the log option in the configuration, ...

On the hardware side, verify your connections to be sure, did you use the capacitor next to the nrf24?, ...

@jvdk What you want to do is possible, but requires a certain amount of electronics hardware knowledge and programming skills.
I think this setup is not a standard within the mysensors library.

Perhaps you should first ask yourself why you want to communicate with the gateway by wire?

The sketch you have found to work with the ultrasonic sensor, normally sends its data via the radio module.
This can be replaced by a serial protocol transport to the gateway, but you will have to write that yourself on both sides, both on the arduino and on the gateway.
There are plenty of examples of code where arduino's talk to each other via the serial ports. On the Pi side you will also have to implement the same serial protocol.
On the hardware side, you must take into account that the distance between the arduino and the Pi, is limited. The arduino and the Pi use a serial signal based on 5V. Be careful with arduino's that run on 3.3V, you will need to put a converter in between. If you want to bridge long distances, you will have to go to an RS485 implementation and not a serial RS232 implementation.

Probably you want a wired solution because of the water tank.
I've read already topics about it, I even think on this forum, about people who did build something equivalent.
You can maybe search first other topics about this to get ideas of building this type of sensor.

@jvdk I don't use a raspberry pi, but searching on this forum I found this topic : https://forum.mysensors.org/topic/11315/raspberry-pi-zero-gateway-with-local-sensor
(important : read the comment to use wait() and NOT delay())
You could get in touch with the author if you have questions.

@tssk In following post I have described my adventures in building a battery powered door node : https://forum.mysensors.org/topic/11499/checking-mechanical-locked-doors-by-a-battery-based-windows-door-sensor-node?_=1614421889744
Search for the section : The battery-based windows/door sensor node : software
I explain there the use of the minicore package.
See also the section References at the end for more information about battery powered nodes

Sorry, but I'm afraid I can't help you any further.
If the tests in the sketch do not go any further, there is something wrong with the board itself...

Do you mean to remove the RFM69HW chip or the complete RFM69HW sub-board?
Removing the sub-board should be possible with a normal soldering iron and a desoldering pump sucker tool.
On internet you will find plenty of information how to desolder components, even on youtube where you can see it...
What for type of soldering iron do you have?

If the provided tests are not passing, there is something wrong.
Can you post some photo's of your board and solderings?

The log output is still the same : the transport is not found.

I would verify and measure the connections of the radio module to the ATSAMD21 µProcessor.
See schematic at https://www.mysensors.org/hardware/sensebender-gateway, search MysensorsGW.pdf
If these are all correct, a faulty RFM69?

Use following for the log parser:

MCO:BGN:INIT GW,CP=RRNGSA--,VER=2.2.0
SGN:PER:OK
SGN:INI:BND OK
TSF:LRT:OK
TSM:INIT
TSF:WUR:MS=0
!TSM:INIT:TSP FAIL
TSM:FAIL:CNT=hu
TSM:FAIL:DIS
TSF:TDI:TSL

This will output:

I would recheck the radio module connections...

@emre299 when you click on Burn Bootloader, you get these errors

avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x03
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x03

So you verified the connections. Did you verify also with a multimeter? A wire can be broken internally

Do you have another pro mini to verify the connections?
I would try different settings like the normal settings 3.3V and 8Mzh externally, etc

If this does not work, I have no ideas anymore...

Ok, you programmed the blink sketch the first time via the ISP way of uploading

• the pro mini at 3.3V : works
• the pro mini at 2.3V : didn't do anything ==> this is already strange, it should also work

Then you did the same using the default way by uploading the sketch via the bootloader

• the pro mini at 3.3V : works
• the pro mini at 2.3V : works

And now you can't upload anymore new sketches to the pro mini.
Of course you upload your sketch with the pro mini again at 3.3V?

Further I should:

• double check your wirings
• is your programmer connected with fixed pinheaders or by folding the programmer a little in the holes of the pro mini? Verify if you have strong connections.
• Reprogram the bootloader. If this works, you should be able to upload a sketch.

Post some photo's that we can see something.

@electrik said in [Tutorial] How to burn 1Mhz & 8Mhz bootloader using Arduino IDE 1.6.5-r5:

@emre299 Did you changed the upload speed in boards.txt?
See in the first message of this topic
https://forum.mysensors.org/uploads/files/1454449114161-9.png

@emre299 did use the Minicore project, so that is different. See my comment just above his.

@emre299 can you describe the steps you did? step by step
Which version of Arduino IDE did you use?
Without more information, it will be difficult to respond to your question.

@TheoL sorry, I didn't have that in mind, but of course that is also a possibility.

With the RF24, we can configure another channel

/**
 * @def MY_RF24_CHANNEL
 * @brief RF channel for the sensor net, 0-125.
 *
 * Frequencies: 2400 Mhz - 2525 Mhz
 *
 * Channels: 126
 * @see https://www.nordicsemi.com/eng/nordic/download_resource/8765/2/42877161/2726
 *
 * - 0 => 2400 Mhz (RF24 channel 1)
 * - 1 => 2401 Mhz (RF24 channel 2)
 * - 76 => 2476 Mhz (RF24 channel 77)
 * - 83 => 2483 Mhz (RF24 channel 84)
 * - 124 => 2524 Mhz (RF24 channel 125)
 * - 125 => 2525 Mhz (RF24 channel 126)
 *
 * In some countries there might be limitations, in Germany for example only the range
 * 2400,0 - 2483,5 Mhz is allowed.
 * @see http://www.bundesnetzagentur.de/SharedDocs/Downloads/DE/Sachgebiete/Telekommunikation/Unternehmen_Institutionen/Frequenzen/Allgemeinzuteilungen/2013_10_WLAN_2,4GHz_pdf.pdf
 */
#ifndef MY_RF24_CHANNEL
#define MY_RF24_CHANNEL (76)
#endif

/**

If we use RFM69 radio, we can define the network ID

#define 	MY_RFM69_NETWORKID   (100)
 	RFM69 Network ID. Use the same for all nodes that will talk to each other.

@Snyfir another approach is to use another radio channel for your B network? That includes of course another gateway also...
An advantage is that you can stick with the standard MySensors library.
More information on : https://www.mysensors.org/download/sensor_api_20 : search channel

of course:
That’s why I want nodes of network (A) use only repeaters of network (A), and nodes of network (B) use repeaters of networks (A) and (B)
This will not be possible....

I tried to compile the sketch for the Sensebender Gateway Sam M0, but indeed with version 1.8.11 Arduino SAMD boards (32-bits ARM Cortex-M0+), this doesn't compile.

To correct the error #include <avr/dtostrf.h> not found, we can adapt the MySensors hal implementation
C:\Users\YourUserName\Documents\Arduino\libraries\MySensors\hal\architecture\SAMD\MyHwSAMD.h

/*
 * The MySensors Arduino library handles the wireless radio link and protocol
 * between your home built sensors/actuators and HA controller of choice.
 * The sensors forms a self healing radio network with optional repeaters. Each
 * repeater and gateway builds a routing tables in EEPROM which keeps track of the
 * network topology allowing messages to be routed to nodes.
 *
 * Created by Henrik Ekblad <henrik.ekblad@mysensors.org>
 * Copyright (C) 2013-2019 Sensnology AB
 * Full contributor list: https://github.com/mysensors/MySensors/graphs/contributors
 *
 * Documentation: http://www.mysensors.org
 * Support Forum: http://forum.mysensors.org
 *
 * This program is free software; you can redistribute it and/or
 * modify it under the terms of the GNU General Public License
 * version 2 as published by the Free Software Foundation.
 */
#ifndef MyHwSAMD_h
#define MyHwSAMD_h

#include <SPI.h>
#include <avr/dtostrf.h>

#ifdef __cplusplus
#include <Arduino.h>
#endif

Replace in the above code the line

#include <avr/dtostrf.h>

by

#include <api/deprecated-avr-comp/avr/dtostrf.h>

Then the compiler will go further, to the next error

C:\Users\YourUserName\Documents\Arduino\libraries\SD\src/utility/SdFat.h:31:10: fatal error: Print.h: No such file or directory
 Not used: C:\Users\YourUserName\Documents\Arduino\libraries\SPI
 #include <Print.h>

This is going to take us too far...
This is also not the way to take. In the correction above, we've introduced already a deprecated path....

The solution is or going back to an older implementation like @BearWithBeard is suggesting
or hoping that @tekka (I'm not sure if the tekka007 on github is the same as here ) can do an update of the MySensors SamD board implementation on https://github.com/mysensors/ArduinoBoards

@TheoL I can't say you which is the best printer
But I can say a word about my experience after 2 years of 3D printing...

I have the Anet A6 printer, purchased from Elektor. At that time it was a promotion sell which included PLA filaments.
It was a kit, but easy to assemble. Usually these types of kits can be expanded by printing parts yourself, what I did. www.thingiverse.com is the place to be.

So what is important if you don't have a 'pro'-type 3D printer (with pro, I mean auto-leveling, multi nozzle, ...)

• place the printer on a flat stable surface (in my case it is screwed to a thick MDF plate so I can move it in and out the cabinet (don't have the place to let the printer stay))
• the adjustment is very important, namely the distance between the nozzle and the bed. If the printer is moved from his place, the printer always needs to be recalibrated!
  You do that by taking a white A4 paper (80gr), put it on the bed and move the nozzle over the plate. You should be able to feel the paper sliding between the plate and the nozzle, not too loose, but not too tight either!
  The first times, this will take the most from your time to prepare the printing, but after a while you become handy at it
• important that the bed can be heated (I have only PLA experience) to a 50-60 degrees Celcius.
• I print always with 'brim' at 3 mm. Why? When the printer starts printing, the PLA will not start directly, so the first 4 à 5 cm are not well printed. With a brim around your piece, you don't have that problem. It helps also to improve bed adhesion.
  Remark : a 'brim' is connected with your piece, after printing you you have to break it down, but that's normally not a problem. You can also use the option 'skirt', same purpose and it is not connected to your printed piece.
  But from experience, I use 'brim'.
• important that the PLA filaments are putted in their plastic bag if not used! Normally when you open the plastic bag the first time, you will find the known little bags with little granules for the humidity. Don't throw them away but let them in the plastic bag. The PLA must be kept dry!
  If you let the PLA in open air too long, say months without using it, you will see that the PLA wire will break more easily.
  Don't skimp on the PLA quality, get a premium quality, even with a cheaper printer
• a glass plate or a special 3D printing surface material is important. It should allow the heat to penetrate well so that the first print lines adhere well to the surface. You will also have a smooth bottom.
• Don't skimp on the possible dimensions. You will regret it later . If the price is affordable, I should take the one with the biggest print volume.

You will find after a while, if you design your own pieces, that the design phase will take the most time.
I myself, use Freecad for 'mechanical' designs and Blender for more artistic designs.
But before designing yourself cases for example, search on www.thingiverse.com or other sites, there are plenty of designs made already. Search even on the MySensors forum for specific node cases

@Geelbuik A SAMD board uses another architecture then AVR boards.
You can try with adding an #include <avr/dtostrf.h> at the top of the sketch to see if it will work.

For more information, see https://forum.arduino.cc/index.php?topic=378874.0

@Diazovitch69 You can use the log parser : https://www.mysensors.org/build/parser

16 MCO:BGN:INIT NODE,CP=RNNNA---,FQ=16,REL=255,VER=2.3.2	Core initialization of NODE, with capabilities RNNNA---, CPU frequency 16 MHz, library version 2.3.2, release 255
26 TSM:INIT	Transition to Init state
28 TSF:WUR:MS=0	Wait until transport ready, timeout 0
34 !TSM:INIT:TSP FAIL	Transport device initialization failed
36 TSM:FAIL:CNT=1	Transition to Failure state, consecutive failure counter is 1
37 TSM:FAIL:DIS	Disable transport
39 TSF:TDI:TSL	Set transport to sleep
10041 TSM:FAIL:RE-INIT	Attempt to re-initialize transport
10043 TSM:INIT	Transition to Init state
10049 !TSM:INIT:TSP FAIL	Transport device initialization failed
10051 TSM:FAIL:CNT=2	Transition to Failure state, consecutive failure counter is 2
10053 TSM:FAIL:DIS	Disable transport
10055 TSF:TDI:TSL	Set transport to sleep

The initialization of the transport is failing. So there is a problem between your arduino? and your radio module.
You should check your wirings!

@mfalkvidd can you please update the article?

Each little thing that can help, is a step forwards

Adafruit for example, has something : https://www.adafruit.com/product/882

A decent multimeter will also measure in the µA range...

@barrydou I don't see directly a problem in your sketch. (Besides, I should use wait everywhere and not delay, with a wait, mysensors can still receive messages).

What is driving your digital input?
It could be that the arduino is detecting something and doesn't sleep well.

You could do an extra test by using following sketch : https://andreasrohner.at/posts/Electronics/How-to-modify-an-Arduino-Pro-Mini-clone-for-low-power-consumption/
With this sketch we are sure that the arduino is sleeping.

So let's recapitulate, you are saying that with your sketch running:

• you measure the current consumption of only the arduino mini as less than 50 µA
• you measure the current consumption of the RFM69W directly in the 3.3V as 2 mA : this is measured between the 3.3V power output and the 3.3V power input of the RFM69W?
  
  (the PCB on the image is a RFM69HW, so your pin layout can be different!)

If the 2mA are measured like in the image, than, if you have a scope, you can see if the inputs like NSS, MOSI, MISO and SCK are changed. It shouldn't during the sleep of the arduino.

You have verified with a loop all your solder points?

Maybe you could also post some photo's of your setup...

Maybe you can also post your sketch, so that we have a complete view...

@skywatch Thanks for wanting to help me.
I have also the SDR# software installed, but was getting quicker a visual result with the other software, that's why I used this software.
So I'm curious how to set my sdr to the optimum level by adjusting the gain.

For photo's you can see them here : https://forum.mysensors.org/topic/11499/checking-mechanical-locked-doors-by-a-battery-based-windows-door-sensor-node
At the end, you have photos of the problem node.

Like said, today, the node was working.
I've reprogrammed also the repeater node, because I was doing a new temperature repeater node and remarked that my sketch code of the first repeater node was missing my encryption key???
I don't know what did happen here. The repeater node was recognized by the gateway and the controller, so the used encryption key is normally correct. Or is a presentation message not encrypted???
Maybe I did a mistake in saving my github sketch where I delete my keys of course
To be sure, I reprogrammed the repeater node with the correct encryption key.

If it happens again, I will check the spectrum and in case it isn't sending something, I will check the node on soldering errors and move also the node upwards in the doorframe.

I will check also the MySensors docs to see how we can see if a repeater node is working and how we can see that a sensor node is using the repeater and not trying to send directly to the gateway.

@skywatch said in RFM69 Range issues:

My point is that if the sdr has a noise floor of say -70dBm and the RFM has a noise floor of -80dBm then the RFM can still 'see' interfereing signals that the sdr doesn't, You can see the signal to noise ration in sdr# by looking at the blue bar to the right of the main spectrum display. To get your sdr set to the optimum level you need to adjust the gain to maximise this figure, then you are operating in the optimal domain for SNR and hence what you can see'hear.

Like said my knowledge is limited in this matter.
Can you give more information about how to do it? Or point me to some How To's?
I use the software SDR Console version software and I think you mean this:

But how to adapt the gain? I played with this, you can move the little white line in this vertical bar up and down, but not knowing what I'm doing is not getting me further

I think that from the picture I can conclude that my environment spectrum is quite, today at least.
My problem is that some messages from this node are not making it to the gateway.
Sometimes it works great for days and then suddenly the node does not send anything.
For this I added already a repeater node between, thinking it would get better, but nada.

My idea is now to measure with the SDR at these moments:

• Is the node trying to send a message or not? If I see nothing, then it is a hardware/battery problem of the node itself. If I see the same signal figure, then it is not my node who has a problem
• Is my environment suddenly filled with other signals? blocking my signal?

@skywatch Based on your answers, I see that you seemingly have knowledge in this matter.
I have range issues and just wanted to see if this is due to external environmental factors (neighbors using the same frequency, etc)
And to spend more than 200 euros for something that I will use maybe one time, that was way too much.
(Purchase price manufacturer 140 euros + 10 euros shipping + import taxes because more than 22 euros + customs clearance = 219 euros). I live in Europe where they specialize in taxes

I know you usually get what you paid for, so I don't expect extraordinary performance either...

@skywatch Yes, it should be better for his price of 219 euros
I bought now the rtlsdr for 29 euros directly from the RTLSDR site from their Chinese store.
My purpose was to see if there was much noise or not in my environment.

Did receive yesterday my RTL-SDR.COM USB stick

A first measure of the spectrum around the 868MHz band from my fix desktop computer with the Airspy SDR# software recommended on the RTL-SDR.COM website.

You see clearly the lines in the waterfall blue section when a node sends something.
With my limited knowledge about radio signals and use of this Airspy SDR# Studio software, I think that the spectrum around my house is relatively quiet?

Yet another printscreen with the SDR Console version software

Will install the software now on my laptop to be able to go near the nodes and gateway.
To be continued.

Already a question, my RFM69HW are working in the 868Mhz band, yet I see movement at 867.970 MHz and 868.020 MHz. At the center 868 MHz, I see no movement.
Someone with more knowledge about this, can explain this? I would expect a signal at 868 MHz...

@joaoabs If you give a picture of the other side?
On this link you will find a chart with pictures that can help to identify your model

You can try with the bear minimum, only the pro mini and the rfm69w feeded directly by 2x 1.5V AA batteries.
A booster and a voltage divider will consume power...

See https://forum.mysensors.org/topic/4796/battery-powered-sensors/243
My minimum with a pro mini and a rfm69HW was 133µA

See also https://forum.mysensors.org/topic/11499/checking-mechanical-locked-doors-by-a-battery-based-windows-door-sensor-node?_=1609880916266
To minimize the current with a closed contact, I did not use the internal pull-up resistor of the 329P (internal pullup resistor value around 30KOhm), but an external 1M ohm resistor. With closed contact and deep sleep, I have now around 136µA.

See also at the end of the topic in the section 'references', you will find plenty of other topics related to current consumption and sleeping.

Ok, the RTL-SDR.COM kit is ordered. So, now waiting for it

Besides the 'how to' question, what are the models used?
I see the Airspy R2 at 219 euros or the Airspy Mini (dongle) at 138 euros, still quite expensive...
And I see a RTL-SDR kit with dipole antenna for 34.95 dollars or 40 to 50 euros in Europe.

@canique The door nodes sketches have code to treat the acks and retransmission, but still sometimes, the messages are lost...

I thought first that it could be because the pro mini's are running on 1MHz and it was reported that MySensors lib didn't work well at this frequency.
But my door node at 3m away from the gateway, didn't miss yet one single message and the nodes are not freezing, the next time the message is getting through.
So maybe there is 'noise' around who is disturbing the radio communication, but how to detect that without professional expensive equipment?
Maybe via this RTL-SDR thing?

@Yveaux, Do you have specific weblinks how to use the rtl-sdr module to debug radio range issues?
I'm searching and reading about it on the net, but till now not yet found a usable debug workflow.

@bjornhallberg are you progressing?

I've also still range issues for my nodes 25m away from my gateway. There are isolated brick walls, sunproof glass, concrete floors, etc between these nodes and the gateway, but when I read about ranges of more then 400m, free sight I suppose, I'm wondering of there are external factors playing a role here...
The nodes are communicating with the gateway, but I loose regularly messages and for door nodes that's a little unfortunate

The RFM69W and RFM69CW have both 13dBm power output, so that can't be the reason.

• You could try to power the buttonsizenode, not by the button battery, but by an external power/battery supply. This to test if it is not a battery button problem not providing enough juice for the radio.
• If same result, try to add an extra 47µF elco or bigger on the power inputs of the radio.
• Do a test with the dBm output set to 13dBm.

Recently, I had a conversation about the ATM with @mfalkvidd.
As result he added following section to https://www.mysensors.org/build/select_gateway

RFM69/RFM95 Special considerations
For gateways using the radio transport RFM69 or RFM95, when MY_GATEWAY_FEATURE is defined, the ATC mode of the gateway is disabled which makes perfectly sense since every node will report a different RSSI and there is no need to change the tx level at every transmission.
However, the default tx power will then be used by the gateway (MY_RFM69_TX_POWER_DBM which is 5 and MY_RFM95_TX_POWER_DBM which is 13) and whereas ATC will increase that value if needed, this is not happening on the gateway which will stay at 5 for RFM69 (or 13 for RFM95) forever despite not running on battery and so without any need to save power.
So if you are having range problems with your gateway, set the define MY_RFMxx_TX_POWER_DBM to a higher level. Be aware that setting this power setting to a higher level, will cause your node or gateway to 'screaming louder'. For nodes very close to the gateway, things could go even worse. So test with little steps.
Finally, pay attention to the hardware version of your radio. For example for RFM69, even though 20dBm may be specified, RFM69 is limited to +13dBm, only RFM69HW can reach real +20dBm. The opposite is also true, only RFM69 can use power values lower than -2dBm, RFM69HW is capped lower than that.

I don't find the topic in question for the moment
Like I did understand it, the ATM starts at the level defined by MY_RFM69_TX_POWER_DBM which is by default 5.
It will then adjust the power to the configured ATC value.

Try first to set the MY_RFM69_TX_POWER_DBM on the gateway to a higher value. Use little steps.

But what I don't understand, your node build as signal scanner is working well in the garage and the mailbox with the current setup?
And the other nodes not?
If their hardware is the same, that is very strange...

@sundberg84 If I get it correct you implemented in your repeater sketch the use of the MySensors indication handler?

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

txOk and txErr are always incremented in the sketch and send to the gateway.
Yet I see in your graphs a hourly count? Graphs from Grafana?
Can you explain how you did this?

@canique The lock mechanism is a standard mechanical lock with a bolt and a normal key.
When you turn the key for closing the lock, the bolt comes forward and pushes the two springs inwards, shorting the two springs.

I'm using normally FreeCad for designing mechanical engineering things (Blender for more artistic things, like my fontain basin: https://www.thingiverse.com/thing:3374672).
Because I'm not designing much, I spend most of my time remembering and finding out how to do things again
If I count every minute together with all the retries and corrections, 2 days, so let's say 16 hours?
(not counting the print time of the prototypes).
An experienced mechanical designer, when he have all the specs, can do this in less than an hour

The trigger to start this project was remarking, for the umpteenth time in the morning, that the door had been unlocked again all night.
Replacing the mechanical locks on the 4 doors by electric locks was out of the question, too expensive and the need for electric cables that were not present.

So, how to detect if a mechanical lock is closed?

The internet is an incredible source of ideas:
https://community.home-assistant.io/t/how-i-made-my-dumb-locks-a-little-smarter/55174
https://community.home-assistant.io/t/i-made-a-simple-lock-sensor-with-xiaomi-door-sensor-some-battery-holders-and-a-soldering-iron/49445
With this idea, let the bolt close a contact, I could use the standard window/door sensor node!
So I made my version by using springs I found in my junk bin mounted on a piece of wood, namely the wooden stick of an ice cream
My first prototype was working, but not really a piece of art

Remember to always drill holes because the wood of the stick splits very easily.

I did use battery springs for my other nodes, they are stronger and easier to use.

The battery-based windows/door sensor node : hardware

I had never built a battery based node before, so as a first step, I did read the site article on the MySensors site: https://www.mysensors.org/build/battery

Luckily, I already had Pro Mini's and enough RFM69HW radios in stock.
Today I know that I did probably the wrong choice by using the Pro Mini’s. They are good in low consumption, but a bare bone 328P used like in this topic https://forum.mysensors.org/topic/2067/my-slim-2aa-battery-node is still better...
But we will see how far these Pro Mini’s will take us on 2x AA batteries!

My first node was based on the idea to use the same enclosure as in the above topic. In Belgium these cable ducts are known under the name Legrand and I had a still a piece of more then 1 meter lying around, a surplus from the renovations.

Because I used a Pro Mini and not a bare bone 328P, I was obliged to use 2 covers of the cable duct instead of a cover and base. The base of the cable duct was not broad enough for the Pro Mini.

With the hardware tricks of the MySensor battery node site article on the Pro Mini, I could obtain a current consumption of 133µA in deep sleep (Modified Pro Mini, RFM69HW and the open contact).

To minimize the current with a closed contact, I did not use the internal pull-up resistor of the 329P (internal pullup resistor value around 30KOhm), but an external 1M ohm resistor. With closed contact and deep sleep, I have now around 136µA.

The battery-based windows/door sensor node : software
Besides the hardware modifications done at the Pro Mini, you can also do software modifications to save power consumption.
In the same topic https://forum.mysensors.org/topic/2067/my-slim-2aa-battery-node, the author @m26872 mentioned the use of a new bootloader with a 1MHz internal clock and a BOD (cpu brown out) disabled.

Today (2020-12-28) we can use the github project MiniCore https://github.com/MCUdude/MiniCore to program our Arduino Pro Mini with the new bootloader. See the readme of the project MiniCore on Github. It explains everything: the theory, the installation and the Getting Started.

After installing MiniCore, I used following configuration:

• board : ATmega328
• clock : internal 1 MHz
• BOD : BOD 1.8V
• EEPROM : EEPROM retained
• Variant : 328P / 328PA
• Bootloader : Yes (UART0)

Remark 1
I did not disable completely the BOD. Why? I did read on forums that the processor could write garbage into the memory when below 1.8V, so for safety’s sake, I did set it to 1.8V.
Remark 2
There are reports that using the Arduino Pro Mini at internal 1Mhz gives sometimes problems with the MySensors library. It was not clear to me if it was with the 1.x version of MySensors or the 2.x version, so I did take my chance and used 1MHz with the 2.3 version of MySensors. Till now, no problems!

You must program the bootloader with an ISP. I used my ‘Arduino as ISP’. See https://forum.mysensors.org/topic/11444/using-an-arduino-uno-as-isp-for-programming-5v-and-3-3v-boards-without-soldering-the-needed-connections

Remark
If your pro mini is already connected to the RFM69HW radio, D11, D12 and D13 are used as MISO, MOSI and SCK for the radio.
These pins are also used to program the bootloader.
This will affect each other. The ISP programmer will not be able to detect the device ID and will fail. You must disconnect these 3 lines from the radio module, the time to (re)program the bootloader.

You can find the used sketch at https://github.com/ericvb/MySensorsArduinoSketches/tree/master/sketches/ArduinoProMiniLockDoorBatterySensorWithEncryptionGithub

So in a nutshell:

1. first program the bootloader via minicore (Arduino IDE : burn bootloader)
2. download the sketch via your normal USB to TTL programmer using the rx, tx, dtr, gnd pins (Arduino IDE : Upload)

The battery-based windows/door sensor node : 3D printing enclosure

Because I had to use the cover of the cable duct as base for the Pro Mini, I decided to design a case with approximately the same dimensions.
The dimensions were dictated by the available space in the PVC door frame, the dimensions of the Pro Mini, the RFM69HW, the 2 AA batteries and the minimum possible printed thickness still solid by my 3D printer:

• Length : 200mm
• Width: 20mm
• Height: 17mm

You can find the design (open source FreeCAD) and STL files at: https://www.thingiverse.com/thing:4659402
The last months the thingiverse website has many problems, designs are not visible, 404 messages, etc.
Post a note if you don't find the 'thing'

The sensor is fastened with Velcro strips to prevent damage to the door caused by using fixing screws.

References

Via following links, you can find more information about minimal power consumption, bootloaders, etc.
Low power Pro Mini

https://www.mysensors.org/build/battery
https://forum.mysensors.org/topic/2067/my-slim-2aa-battery-node
https://forum.mysensors.org/topic/486/my-2aa-battery-sensor
https://iot-playground.com/blog/2-uncategorised/10-low-power-door-window-sensor
https://iot-playground.com/blog/2-uncategorised/9-arduino-low-power-sensor
http://www.gammon.com.au/power
https://www.iot-experiments.com/arduino-pro-mini-power-consumption/
https://forum.pimatic.org/topic/383/tips-battery-powered-sensors/

Battery consumption

https://forum.mysensors.org/topic/10426/ds18b20-on-2xaaa-battery
https://andreasrohner.at/posts/Electronics/How-to-modify-an-Arduino-Pro-Mini-clone-for-low-power-consumption/

Specific commercial hardware

https://www.canique.com (power efficient board with RFM69HW)
https://www.tindie.com/stores/easysensors/
https://www.tindie.com/products/vysocan/rfm69-radio-node-mini/

Use of bootloaders

https://www.iot-experiments.com/arduino-pro-mini-1mhz-1-8v/
https://forum.mysensors.org/topic/7296/how-to-burn-fuses-so-that-pro-mini-3-3v-would-go-down-to-1-8v-solved/17
https://forum.mysensors.org/topic/3018/tutorial-how-to-burn-1mhz-8mhz-bootloader-using-arduino-ide-1-6-5-r5
https://forum.mysensors.org/topic/3657/mymultisensors/144
https://forum.mysensors.org/topic/5478/how-to-get-longest-battery-life/42

@boanjo a very nice design, not only functional, but also pleasing to the eye.
I've seen your same based design for the temperature node on your thingiverse account, I like that.
I think that I can sell this to my wife to put that in the house

Where did you buy your pro mini's? How did you get a deep sleep consumption of only 35 µA?
See my adventures : https://forum.mysensors.org/topic/4796/battery-powered-sensors/242

@canique no, the purpose of the node is to know when the door is locked by the bolt, not only closed. What you see are simply 2 battery springs and the bolt of the lock closes the contact.
I can move the node more upwards the door frame (and I will do it if the radio connection is still not reliable with the repeater).
In order to preserve domestic peace, I placed the nodes in the door frame, invisible when the door is closed: no visible dangling wires and no visible boxes.

Maybe an idea for a MK3 version of your board as wide as the RFM69HW

@Yveaux It is not a aluminium door frame, but a PVC door frame (plastic).
The problem is that my gateway is in the extension of the brick wall, about 15m away in the garage at the backyard. So I have a 5m brick wall between de node and the gateway
This means that the reliability of the connection is not good, so I had to place a repeater node between them.

@canique you confirm my suspicions. For the moment I have 3 working battery nodes with the pro mini and the RFM69HW. We will see how long the batteries are going to last. Normally it should be one year.

I'm constrained by the maximum dimensions of the sensor node. The case must go inside the PVC door frame, so it can be maximum 20mm width on 17mm height, the length is not a constraint.

I had to solder the RFM69HW in line with the pro mini.
The MK2 boards are unfortunately too wide.

A second thought about using the MySensors method indication.

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

A successful or failed transmission of the error message itself, will also trigger this method, which then actually gives a wrong picture.
Or has this been thought through too far?

@BearWithBeard thanks for your code samples, it confirms my own thoughts and gives a code guideline at the same time

@mfalkvidd, in the reply of @BearWithBeard, he linked to another topic post where you use the indication handler in your sketch.
TxOk and TxErr are send to the controller. Their values are always incremented to infinity by your sketch?
How do you interpret this at the controller?

@sundberg84 says : INDICATION_GW_TX sounds like a good plan. This is a great tool I think for the future to evaluate and debug your network. I used S_CUSTOM and a utility meter (hourly) in HA to get the values.
Do you have a code sample of your sketch? An example generally says more then 1000 words
I think you send each time a value '1' when an error occurs, correct? And on the HA side you use the hourly utility meter integration to sum the values on a hourly base?

@Didou let's then keep our fingers crossed that it's just a software problem

Hi @mfalkvidd

Ok, I understand your point. Did read trough plenty of topics on this
Should be an article on the official website and not spread over so many different topics, hint, hint

Ok, let change the title then to Best practice for the possible workarounds for hardware and software ack when using a battery node.

Physically, because we are using radio, we can't have a 100% situation, but we can aim to it.

• checking the return of the send method and retrying yourself x times by the sketch code, can already help to aim for the 100%.
  The radio nrf24 and I imagine also the rfm69?, does already hardware retries, together with the software user retries, will increase the possibility that the message is delivered... with the comment that a message may arrive several times on the controller!
  Is there a best practice in this workaround? Experiences from members?

• can my first point also be done on a repeater? Because the 'repeating' is done by the library...
  Can we override or intercept this library behaviour?

• the echo reply mechanism or what I'm calling the software ack
  That's the one I doubt to be usable in battery nodes, but maybe members have positive or negative experiences with this?

There are plenty of old and recent topics about the hard- and software ack, but I didn't find a best practice to follow

Let's begin with the documentation

bool send (MyMessage & msg, const bool requestEcho = false )		
Sends a message to gateway or one of the other nodes in the radio network

Parameters
* msg: Message to send
* requestEcho: Set this to true if you want destination node to echo the message back to this node. Default is not to request echo. If set to true, the final destination will echo back the contents of the message, triggering the receive() function on the original node with a copy of the message, with message.isEcho() set to true and sender/destination switched.

Returns
Returns true if message reached the first stop on its way to destination.

send(msg.set(value==HIGH ? 0 : 1));

If the method send returns with true, the hardware ack did work.

• battery node <==> gateway : we are sure, the message is delivered to the gateway
• battery node <==> repeater <==> gateway : we are sure, the message is delivered to the repeater, but further on, we don't know.

If the method send returns with false, the hardware ack did not work, the message is not delivered.
So, what is here the best practice?
Doing this for example in the battery node?

if (!send(msg.set(value==HIGH ? 0 : 1)))
  if (!send(msg.set(value==HIGH ? 0 : 1)))
    if (!send(msg.set(value==HIGH ? 0 : 1)))

3 times or 4 times or 5 times or...
==> a method who retries x times, goes to sleep for a short time, retries again, etc. ?
It should be possible to combine this with the normal interrupt based sleep of the battery door node.

How does the repeater node handles the hardware ack?
Everything is handled by the mysensors library. Is there a way to do here the same in case of a failing hardware ack?
==> if each node (normal and repeater nodes) auto retries to deliver the message, we are sure that the message gets delivered.
But then another the question arises, what if the repeater receives 10 messages from different nodes to forward and the repeater is still retrying to deliver the first? It must create a sort of queue and have enough memory to stock the messages...

Is using the software ack better?

send(msg.set(value==HIGH ? 0 : 1), true);

and implement in the receive method the check of the returning message.
But this means that a battery node must stay awake...
What if no return ack message is received after 5 seconds or 10 seconds?
Resend the message? But we are in the receive method, I don't know if we can send here messages???

The reason for this question is a battery door node at the edge of reliable radio connection with the gateway. I did add a repeater node in the middle, but still sometimes the message gets lost...

@mfalkvidd, I tried to upload them, but still the same error, stl is not allowed as type.

Meanwhile I printed the original files on my 3D printer, but for my EasyPCB RFM69 version, there are some problems. Maybe the board is not the same as the first EasyPCB Nrf24l01+ version of the board?
So I adapted the original sketchup design for the RFM69 version.
I will upload these files to my thingiverse place when ready and verified.

Edit: the modified files are uploaded

• EasyPCB_RFM69_Box.stl
• EasyPCB_RFM69_Cover.stl
• EasyPCB_RFM69_BoxCover.stl
• EasyPCB_RFM69.skp

@Didou, if I understand it well, you have a few NRF modules build.
Each module consist of one NRF5 board, relais, pilot connections for heating control and powered by a onboard 220V AC convertor module. All this packed together in a 2 DIN unit module inside your house power panel = electrical cabinet of your house?

If my understanding is correct, the first thing I think of, is electrical influence of the high AC voltages inside your electrical cabinet. Don't know where you live, but are we speaking of 220/250V or 380V?
Low voltage applications powered by 5V or 3.3V do not like noisy environments like a electrical cabinet.

How long are the pilot wires to your heaters? Long wires act as antennas...
Did you try to operate them outside your electrical cabinet on a test basis?

@Jmarcusse, I agree totally with @skywatch
That's the reason why I use a simple power adapter where it is possible. For example an USB power adapter from an old smarthphone or adapter from a known manufacturer like the PSSE0910BN from Velleman (very well know in Belgium). The latter are more expensive, but safer!

If you still want to incorporate the 220V convertor module in your design, consider the proposal of @skywatch ==> an air gap between them ==> make two PCB's, one with only the 220V power module and one with the low voltage components...

@Jmarcusse, glad to be of any help

I would recommend searching the internet for PCB design tips on how to deal with the high dangerous voltage 220V and the low voltage of 5V on one PCB.
I know for sure that there are technical requirements in terms of distance between print tracks when working with 220V.

Maybe other members can give tips here or links to documentation?
In the Openhardware.io section you can find designs of members working with 220V on their nodes: search for '220V'.
It can be a base to correct your design.

Please report back if you have a new working design
Merry christmas and happy new year.

For people searching the complete stl files of the box and the cover.
I exported them again from the sketchup file.

Hmm, how to upload files here? Only images are allowed by the server?
I've uploaded them to my thingiverse place: https://www.thingiverse.com/thing:4694746

Anyway, I will describe it too

• download the sketchup zip file from the first post
• dezip it and get the skp file
• get an account on the Sketchup online website (free version)
• open the sketchup file
• export to stl via the menu at the left

If you want the two parts apart, delete one of them in the sketchup designer and export the other. Don't save!!!
Do undo and delete the other part. Export now the remaining part.

Thanks for the contribution.
You could maybe upload it also to www.thingiverse.com, so that more people can find it

@mfalkvidd, ok then I understand the error.
Node 100 is my display node that I am also testing and it isn't connected for the moment.

Maybe a good extension for the logparser code? --> it should mention this extra information

Thanks a lot!

The logparser isn't giving more information.
Does somebody knows what it means?

@Jmarcusse said in Supply 230V/5V for node ? Mini Pro, NRF24L01, ams1117:

For the internaly drawing of MiniPRo you send me, I don't very understand where is connected the Vcc of FTDI Basic JP1. Does we understand all is named "Vcc" are the same Vcc?
Do you think I have to shunt my 2 differents Vcc? will burn or not burn....

Normally it is the same VCC.
We can test it. If you connect your USB to FTDI cable, do you measure 5V on the normal VCC?
And the opposite: connect the batterypack to the normal VCC and measure the VCC on the FTDI header?
Where did you buy these pro mini's? Do they have a schematic?
Don't shunt them without knowing the schematic, because you can burn something!

Another test you can do, but be very carefull because you are working with 220V AC!!!!!
If you have a spare part of the bought AC power PCB module, connect it not on the PCB you designed, but use it separately next to your PCB (let's say 30cm away) and connect only the GND and 5V to your PCB.
If that is working, you are 100% sure that the current 220V AC design on your PCB is the problem.

@Jmarcusse said in Supply 230V/5V for node ? Mini Pro, NRF24L01, ams1117:

I take a MiniPRo just arrived (open satchel plastic), out off voltage, the 2 Vcc pins are not connected, sure : 85ko between both, or10,4Mo if I reverse ohmeter... I test it in the minute.

Strange, mine are giving 0 ohm between them. It should be 0 ohm.

But let's resume the tests:

• pro mini powered by USB via FTDI header: working --> the onboard AC power convertor not connected and we use the VCC pin of the FTDI header: the leds are working so the pro mini sketch is correctly working.
• pro mini powered by battery pack : working --> the onboard AC power convertor not connected and we use the normal VCC pin of the pro mini: the leds are working so the pro mini sketch is correctly working.
• pro mini powered by the onboard AC power convertor : not working --> is using the normal VCC pin of the pro mini

Did you design this pcb yourself?
I see the GND print trace going near the AC print traces and under the AC power convertor.
I'm not a PCB specialist, but just using common logic sense, for me high voltage AC print traces and low voltage print traces should be as far apart as possible.

Do you have a scoop to see the 5V signal when powered by USB and powered by the onboard AC power convertor?

Are we speaking about a 5V pro mini or a 3.3V pro mini?

• In case of a 5V pro mini, are you connecting the 5V output of the 220V AC power board to the VCC pin or to the RAW pin? It should be the VCC pin if you have 5V.
  The RAW pin is connected to the voltage regulator of the pro mini and should be between 6V and 12V)

The VCC pin on the FTDI header and the normal VCC pin are connected together in my version of pro mini boards. Are you saying that this is not the case with your board?

• in case of a 3.3V pro mini, you must connect the 5V to the RAW pin or connect the 3.3V from the ams1117 to the VCC pin on the pro mini.

Do you have an electronic schema?
Did you verify the soldered connections between the power supply and the pro mini? And the ground connections?
Did you try with another pro mini?
When you tried with the battery pack, was it connected to the FTDI VCC header pin or the normal VCC pin?

To get the status of different door nodes on my LCD node there are two methods:

• direct node to node communication: The sending node is not only sending his status to the controller, but also directly to the LCD node
  In short the code in the door node for sending his status to the LCD node:

#define LCD_NODE_ID 100
#define LCD_CHILD_ID 4  //destination virtual child sensor of the LCD  node

#define CHILD_ID 1  // Each radio node can report data for up to 254 different child sensors. You are free to choose the child id yourself.  You should avoid using child-id 255 because it is used for things like sending in battery level and other (protocol internal) node specific information.
...
MyMessage msg(CHILD_ID,V_TRIPPED);
MyMessage msgLCD(LCD_CHILD_ID, V_STATUS);

Then in the loop method

     send(msg.set(value==HIGH ? 0 : 1)); // to the gateway ==> controller
     send(msgLCD.setDestination(LCD_NODE_ID).set(value==HIGH ? 0 : 1)); // send also to LCD node

• by polling the controller to get the status of other sensors:
  You could do it only with node to node communication, but what if the distance it too long between the nodes to have a reliable connection? Some battery nodes are close to the gateway, but (too) far from the LCD node.
  Also the battery nodes are sleeping most of the time, so directly requesting them will not work!

A node can request data from the controller or from a node.
From the docs:

bool request (const uint8_t childSensorId, const uint8_t variableType, const uint8_t destination = GATEWAY_ADDRESS)
		
Requests a value from gateway or some other sensor in the radio network. Make sure to add callback-method in begin-method to handle request responses.

Parameters
childSensorId	The unique child id for the different sensors connected to this Arduino. 0-254.
variableType	The variableType to fetch
destination	The nodeId of other node in radio network. Default is gateway
Returns
true Returns true if message reached the first stop on its way to destination.

When requesting from the controller, there is no way to requesting data from another node. A node can only request data from itself.
Workaround:

• create child sensors (S_CUSTOM & V_CUSTOM) in the LCD node, one child sensor for each external node you want the status from and send these values to the controller.
• get the controller so far that he is copying the statuses of the wanted nodes to these fields
• request this data again from the controller (polling)

How?
See the sketch for detailed information (https://github.com/ericvb/MySensorsArduinoSketches/blob/master/sketches/ArduinoLCDDisplaySensorWithEncryptionGithub/ArduinoLCDDisplaySensorWithEncryptionGithub.ino), but in short

• Present the child sensors in the LCD node

  // Register all sensors to gw (they will be created as child devices) by their ID and S_TYPE
  // for Home Assistant : S_CUSTOM together with V_CUSTOM
  present(LCD_CHILD_ID_pGarBike, S_CUSTOM);
  

• Create only the first time the child devices in the loop (not sure anymore if this is really needed, was done during my tests). Put in comments after the first run!

  send(MyMessage(LCD_CHILD_ID_pGarBike,V_CUSTOM).set(1));
  

• Let the controller copy the statuses from the other nodes in these child devices
• Request the data from the controller

  request(LCD_CHILD_ID_pGarBike, V_CUSTOM);
  

• Treat the requested message in the receive method of the LCD node

How to let the controller Home Assistant copy statuses from one node to the child devices of the LCD node?
Maybe first a little word how MySensors is integrated in HA.
When nodes are presenting them selves to HA, the Mysensors integration will create a mysensors.json (by default a mysensors.pickle file, but I reconfigured this to create a human readable json file) with your gateway(s) and nodes.

{
    "0": {
        "sensor_id": 0,
        "children": {},
        "type": 18,
        "sketch_name": null,
        "sketch_version": null,
        "battery_level": 0,
        "protocol_version": "2.3.2",
        "heartbeat": 0
    },
    "1": {
        "sensor_id": 1,
        "children": {
            "1": {
                "id": 1,
                "type": 15,
                "description": "",
                "values": {
                    "13": "11"
                }
            }
        },
        "type": 17,
        "sketch_name": "Distance Sensor",
        "sketch_version": "1.2",
        "battery_level": 0,
        "protocol_version": "2.3.2",
        "heartbeat": 0
    },
    "100": {
        "sensor_id": 100,
        "children": {
            "1": {
                "id": 1,
                "type": 23,
                "description": "",
                "values": {
                    "48": "0"
                }
            }
        },
        "type": 18,
        "sketch_name": "LCD Display Panel Sensor",
        "sketch_version": "1.1",
        "battery_level": 0,
        "protocol_version": "2.3.2",
        "heartbeat": 7207526
    }
}

The values of the child sensors are putted in this file and read by the normal workflow of HA, see the "100" entry above.

Home Assistant itself has nothing, I'm aware of, to copy or notify another sensor that a value/status of a device, did change.

So in a first attempt I did use a custom python script from the HA community who could, with the help of an automatization, change a status and/or attributes for a given entity_id when the status of another entity did change (= trigger).
This worked in the screens of HA, but the values in the json file didn't change and when requesting data from the controller by the LCD node or when HA did resync itself, the values of the json file were again taken, throwing away the modified values of the custom python script.

A second attempt was to try to read the python code of the MySensors integration, but I must admin, my python skills are not so great

After many thoughts and tests, my eyes just opened up, if I used an automatization with the mqtt push service, simulating a fake mqtt message apparently coming from the gateway saying that the child sensor had a new payload?
Bingo, that worked

So two HA automatizations for each child devices, are triggered each minute to verify what the status is of the other device/sensor. Depending on the status, one of the automatizations will put a mqtt message on the mqtt bus.
For example:

topic: mysensorsgateway-out/100/3/1/0/48
payload: 1

• mysensorsgateway-out: simulates that it comes from the gateway
• 100 : the LCD node id
• 3 : the LCD child sensor id
• 1 : the message type: defines what the message contains and what the sub-type means: here the 'set' message type
  - Presentation (0): Contains the S_xxx sensor type
  - set/req (1/2): Contains the V_xxx data type
  - Internal (3): Contains an I_xxx constant that describes what the payload is - ex. I_CONFIG (6) or I_SKETCH_VERSION (12) from my example above
  - stream (4): for fw update.
• 0 : ack field : The **ack **field is used to know if a message is an ack to a previous message or a real message. I assume here a normal real message, so it will be always 0.
• 48 : the sub-type = the V_CUSTOM field

HA is also subscribed to this topic, so it will consume directly this message, setting the correct fields in the mysensors.json file!
Probably these two automations can be refactored to one automation with conditions in the action, but that must be still found out.
Example of one automatization that triggers each minute:

@Jmarcusse, I imagine that you measured, with the 220V connected, everywhere the 5V and 3.3V and that they are all correct.
I'm seeing a custom PCB, so I imagine you are aware of the risks of working directly with 220V AC

Then I should do following debugging workflow:

• Verify if the pro mini is running correctly : connect the pro mini via your ttl to usb cable to the laptop and look at the debug messages. Is the pro mini sending his radio messages?
  With extra debug serial prints in your sketch, you can verify if the program is running correctly.

• The convertor circuit to make 5V and 3.3V from 220V AC is maybe producing to much noise.
  So two tests we can do:
  First test: try to put a metallic shield between the AC part of the PCB and the radio. Connect the metallic plate to the earth of the 220V. But pay a very high attention for short-circuits by error, especially if there are bare contact points at the 220V level on the PCB!!!!
  Second test: deconnect your NRF24LO1 from the PCB and reconnect the radio with wires to move the radio further away from the AC power. Of course make these wires not too long, because they can act as antenna's, making it even worse.
  It is maybe easier to do directly the second test with an external shield outside the plastic box...

Is this convertor circuit your own design of a bought one?

@Sandolution , @bwn , @electrik
Did anyone of you find a solution for this problem?

@bollarcreets, I am afraid that the script has never been adapted to the evolution of the IRRemote library.
If you take library version 2.2.3, the script will compile.

If you take the source code from the latest version 2.8.1 you will also see that the typedef enums AIWA_RC_T501 and MITSUBISHI are commented out.

If you want to run this example script with the latest version of the library, you will need to analyse and understand the script in order to modify it...

@Joost, bumping

@Joost I measured the current with another, even older, analog type of multimeter, a type where you need to read the needle using an integrated mirror
It is measuring approximately the same deep sleep current: 141µA

Maybe the two multimeters are not correct, but they all give the same order of magnitude.

Next weekend, I will redo a measuring:

• a new Pro Mini + sketch deepsleep from lowpowerlab
• the same Pro Mini without the power led + sketch deepsleep from lowpowerlab
• the same Pro Mini without the power led and regulator + sketch deepsleep from lowpowerlab

To be continued

PS: @Joost, did you see my message about your breakout pcb to be able to order it via openhardware.io?

@olka Thanks for the tips. I'm already doing the last 2 tips.
Concerning the first tip, you mean to program directly the sketch via the ISP and not the normal way to upload via the bootloader?
Didn't know that this also saves some power.

@Yveaux I'm already using your VCC library

@Joost I like your solution to be able to use other pins as pin change interrupts together with Timer interrupts in the MySensors library.

I did use the default sleep function of MySensors with the foreseen D1 and D2 pins where D1 is already taken by the radio, so only D2 is usable for custom use.
See https://www.mysensors.org/download/sensor_api_20#sleeping