@BearWithBeard
Hmmm... I didn't realise the Version is supposed to go in the configuration file as well. The version is correctly listed in my persistance-file but I'm not so sure if I have it in my configuration file.
But, reading the Serial Protocol for mysensors it clearly says that "V_UNIT_PREFIX" is used by "S_DISTANCE, S_DUST, S_AIR_QUALITY" so perhaps the error message is correct?
I'll report back later tonight.
Have you set it up for 434mhz? I think the standard is 866 mhz if not redefined. Also delay is important for certain settings.
I have the same chip working at home, I'll post code tomorrow.
Hi!
I wanted to add some temperature sensors to my gateway as it is situated very nicely in the house and will cover four rooms pretty easily. Everything seems to be working just as it should but I am getting annoying warning messages in my Home Assistant logs:
2020-04-13 17:02:24 WARNING (MainThread) [mysensors.message] Error decoding message from gateway, bad data received: Sending DATA
2020-04-13 17:02:24 WARNING (MainThread) [mysensors] Not a valid message: not enough values to unpack (expected 5, got 0)
My theory this far is when looking at the serial output of the gateway a locally attatched sensor differs from a remote node.
Example from node:
0;255;3;0;9;39174 TSF:MSG:READ,3-3-0,s=1,c=1,t=18,pt=7,l=5,sg=0:278.0930
Example from local sensor:
0;4;1;0;0;24.2
So my guess is that home assistant is trying to unpack the data that normally comes with the message but with the local node there is none.
I could just ignore the warning but i thought i would ask if anyone have found a solution for problem?
#define MY_RADIO_RFM95
#define MY_DEBUG_VERBOSE_RFM95
#define MY_RFM95_FREQUENCY (RFM95_434MHZ)
#define MY_RFM95_MODEM_CONFIGRUATION RFM95_BW125CR48SF4096
#define RFM95_RETRY_TIMEOUT_MS (3000ul)
#define MY_TRANSPORT_STATE_TIMEOUT_MS (3000ul)
These are the defines I'm using. All done before including the MySensors.h.
What do you get if you try the above?
Well... At last I got some time to dig in to the problem and it turns out it was a quick 10-minute fix. The fix is quick and dirty and if someone have an idea of how to make it prettier that would be nice.
Anyways.. I really like the RA-01 and RA-02 from AI-thinker and I have been using them for many types of projects so when I saw that the pinout was the same on my module and the nrf24 I was quite happy. Upon plugging the module in and activating MY_DEBUG_VERBOSE_RFM95 option it prints the following:
RFM95:INIT:PIN,CS=24,IQP=32,IQN=32,RST=43
!RFM95:INIT:SANCHK FAIL
Checking the documentation I see that the rfm24 uses different pins on the SAMD compared to the rfm69hw.
I then went in to the variant.h file of the Sensebender and from row 245 and on the definitions needs to be altered.
#define MY_RFM95_SPI_CS (29ul) // Changed from 30
#define MY_RFM95_IRQ_PIN (31ul) // Changed from 32
#define MY_RFM95_IRQ_NUM (31ul) // Changed from 32
Upon compiling and uploading i get:
RFM95:INIT:PIN,CS=24,IQP=32,IQN=32,RST=43
!RFM95:INIT:SANCHK FAIL
So i notice the CS-pin is 24 even though i defined MY_RFM95_SPI_CS as 29.
Searching the variant.h file for 24u I find change the following on row 156:
#define PIN_SPI_SS (29u) // Changed from 24
Upon compiling and uploading I see:
0;255;3;0;9;3932 RFM95:INIT
0;255;3;0;9;3937 RFM95:INIT:PIN,CS=29,IQP=31,IQN=31,RST=43
0;255;3;0;9;3947 RFM95:PTX:LEVEL=13
0;255;3;0;9;3948 TSM:INIT:TSP OK
0;255;3;0;9;3948 TSM:INIT:GW MODE
0;255;3;0;9;3948 TSM:READY:ID=0,PAR=0,DIS=0
0;255;3;0;9;3948 MCO:REG:NOT NEEDED
0;255;3;0;14;Gateway startup complete.
0;255;0;0;18;2.3.2
0;255;3;0;9;3949 MCO:BGN:STP
0;255;3;0;9;3949 MCO:BGN:INIT OK,TSP=1
0;255;3;0;9;3949 TSM:READY:NWD REQ
0;255;3;0;9;3949 RFM95:SWR:SEND,TO=255,SEQ=0,RETRY=0
0;255;3;0;9;4010 ?TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=NACK:
0;255;3;0;9;21316 RFM95:SAC:SEND ACK,TO=3,SEQ=1636,RSSI=-60,SNR=10
0;255;3;0;9;22566 TSF:MSG:READ,3-3-0,s=2,c=1,t=17,pt=5,l=4,sg=0:351
The messages are coming in!
I tried doing the defines in my sketch but the PIN_SPI_SS is overwritten.
So for anyone wanting to use the RA-01 or RA-02 (SX1278) instead of the nRF24, go ahead!
I am not really sure I understand why the HAL is using the "PIN_SPI_SS" instead of the "MY_RFM95_SPI_CS"
Isn't CE,SS,CS all different names for the same thing?
@mfalkvidd
Yes that did it!
Using the following defines:
#define MY_RFM95_CS_PIN (29u)
#define MY_RFM95_IRQ_PIN (31u)
#define MY_RFM95_IRQ_NUM (31u)
I have now restored my variant.h file and all is well.
Also tried to find information about how the RFM95 and SX127x relates to each other. Seems like they share the exact same registers but one is semtech and one the hoperf? Did Hoperf make it the same on purpose or do they license the modem from semtech?
@Avamander Found the documentation you were referring to and yes. Seems to be true for the RF24 which I haven't used in a long time.
#define MY_RX_MESSAGE_BUFFER_FEATURE
This enables the receiving buffer feature.
This feature is currently not supported for anything but RF24. Require MY_RF24_IRQ_PIN to be set.
Note: Not supported on ESP8266, ESP32, STM32, nRF5 and sketches that use SoftSPI. See below issue for details https://github.com/mysensors/MySensors/issues/1128
Definition at line 2406 of file MyConfig.h.
I have tried the nRF24 and sx1278 and have had success with both. I ended up choosing the sx1278 even before exploring the world of mysensors mainly because I really liked the library by Sandeep Mistry. I never had an issue with range. In my old apartment I collected pulses from my electricity meter which was located four concrete stories below without a problem.
Regarding the 9V battery I also did some experimenting with this and the key, if I remember correctly, is to find a VR with very low Iq( quiescent current). In the end I ended up going with dual AA batteries which worked to a surprisingly low voltage. There is a lot written about battery powered electronics if you start to dig a little bit.
I have tried the nRF24 and sx1278 and have had success with both. I ended up choosing the sx1278 even before exploring the world of mysensors mainly because I really liked the library by Sandeep Mistry. I never had an issue with range. In my old apartment I collected pulses from my electricity meter which was located four concrete stories below without a problem.
Regarding the 9V battery I also did some experimenting with this and the key, if I remember correctly, is to find a VR with very low Iq( quiescent current). In the end I ended up going with dual AA batteries which worked to a surprisingly low voltage. There is a lot written about battery powered electronics if you start to dig a little bit.
Not really sure what to make of the log. To me it looks like it isn't connecting properly with the gateway but the picture from MYSController (I have never tried the software) looks promising as it has exchanged information about sketch name, version and so on. I'm also new to MySensors so i'm not able to say what has changed from the two versions. What was the default parameters for nRF24 in 1.5? Amplification and so on.
Hopefully someone else could be of more help...
What happens after the TSM:FPAR:OK ? It seems like the interesting stuffs happens after that part?
@sindrome73 Like @BearWithBeard wrote, reading Nick Gammons guide is a must! I read it and used most of the stuff in there when I was making my battery node. The analog converter is super easy to turn of, ADCSRA = 0 does it. It's also in the guide by Gammon.
Regarding the Minicore definitions, see here: https://github.com/MCUdude/MiniCore
Just follow the "how to install" and when it's added in Arduino IDE you select the relevant options in the Tools menu under "board". Then select your programmer (also in tools menu) and finally "Burn bootloader".
Edit:
Did a quick google on the sensor. Found this: https://www.iot-experiments.com/pir-sensors-hc-sr501/
I just took a quick glance but it seems relevant.
For manipulating fuses I use the minicore board definitions by mcudude( Google for the GitHub) in Arduino IDE. It's really nice to be able to set the BOD level. It's also handy when writing to atmega 328pb if you try that in the future. One of the big things drawing current is the analog converter. Disabling it saved quite a lot if I remember correctly.
What is the current draw of the sensor itself?
@Avamander Found the documentation you were referring to and yes. Seems to be true for the RF24 which I haven't used in a long time.
#define MY_RX_MESSAGE_BUFFER_FEATURE
This enables the receiving buffer feature.
This feature is currently not supported for anything but RF24. Require MY_RF24_IRQ_PIN to be set.
Note: Not supported on ESP8266, ESP32, STM32, nRF5 and sketches that use SoftSPI. See below issue for details https://github.com/mysensors/MySensors/issues/1128
Definition at line 2406 of file MyConfig.h.
@Avamander Regarding the interrupt pin, at least when using the RFM95 I need to have the pin connected to be able to receive anything. It doesnt poll the module to check for incoming messages. Maybe its different with nRF24.
I haven't tried messing with the MY_RX_MESSAGE_BUFFER_FEATURE so I wouldnt know about that.
@Avamander I meant, have you erased the EEPROM of the gateway?
@cYnd Well I'm out of ideas. Could be a hardware issue, perhaps you shorted something when handling the module or you exposed it to 5V?
Is the VCC output from the Mini 5V or 3.3V? If you supply the mini board with 3.3V you should connect the module VCC to 'raw' if i remember correctly.
I use the RA-01 and RA-02 all the time so hopefully you will be very pleased with them. Good luck!
I'm not super experienced using mysensors but I do have 3 nodes working and when first settings things up I had some problems with NODE IDs. It looks like you are setting a Static node Id? Is that ID "free" in the gateway? Have you tried powering of all the nodes you have running, wiping the EEPROM of the gateway, powering up the gateway and shortly after powering up the node?
Someone else perhaps knows this better but, if the gateway don't want to include the node, does that generate the FPAR:No reply?
And also, how is the interrupt pin connected?