@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.