Troubleshooting

For a different approach, how would you manually force a sensor to change it's state (for a binary sensor) from the gateway?

As already meintioned by @kimot and @gohan, the rfm69hcw comes in different versions. From the datasheet, there are four versions: [image: 1521101398513-img_2347-resized.png] Each versions support a frequency range. This is also shown in the datasheet: [image: 1521101442728-img_2346-resized.png] @Qwe-Qwe you need to buy a version that matches your frequency, and cut/buy an antenna that also matches the frequency.

@Nca78 Thank you so much for your incite. John

Not sure if it is the same problem, but looking similar ? I upgrade my MQTT gateway to 2.2.0 (from 2.1.0), all working ok with my 2.1.0 sensor nodes I upgrade the first sensor node to 2.2.0, and I get TSM:INIT:TSP FAIL messages on the node. I downgrade the first sensor node back to 2.1.0 and it works again like a charm ... Did I miss something ? Is this a bug in 2.2.0 ? Do I need to change config ? Best regards, DirkB

Mysensors is nice, but for your task with ESP2866 I can recommend ESPeasy. 30 min and you are done.

@ben999 Sorry for the delay. Work has been crazy lately. I see there are plenty of answers above and I echo them. I try not to upload with two power sources connected. If everything is 5v you are probably safe but I see you're using batteries and I'd not risk it just to be safe. I have used two power sources in the past but I have since changed my ways. I can't remember what stopped me but I believe I was getting strange results. I don't think I ever fried any hardware but why risk it...? :) If you are still having this issue have you tried with another Pro Mini and different code? Is anything coming out of the serial monitor or is it just blank?

@b1ackra1n good news 👍

Hi, The RFM69 is more power hungry than nrf24, so you also need the decoupling capacitor, especially if using the high power rfm69 version. To be sure, you're using high power version on your node, right? as you're using MY_IS_RFM69HW RFM69 is not 5v tolerant (mentioned in the build howto). It's not only about rfm69 vcc, but also about its SPI signals pins, irq etc. when using arduino uno, the atmel mcu is 5v powered (the 3v regulator is external). so the atmel is 5v, and send signals to rfm69 with 5v voltage. not good. max voltage recommended by datasheet is 3.9v. so you could fry it or get malfunction. could you retry with a 3v arduino? if it's still not working then, try with a fresh radio module and check connection.

Ah! Sorry, misprint. Now using 2.2.0, not 2.0.0!

Thanks @mfalkvidd and @gohan . That helped.

@tommy-petersen great work. Thanks for reporting back.

Btw, POSITIVE is created here: https://github.com/mysensors/MySensorsArduinoExamples/blob/4a645c332432412a6308d7df82eee01a3ca68b24/libraries/LiquidCrystal/LCD.h#L187 which is included by LiquidCrystal.h which is included in the irrigation sketch.

Ok, my setup is running now (including personalization, encryption, and soft signing) and stuff is published to mqtt. Thanks everyone for the help! I really like this community. Now I need to resolve the issue with the OpenHAB binding but that's no topic for here.

@mfalkvidd Very Good!! Tanks so much by, have nuce day

@dirkc Unfortunately I cannot test the setup right now, but this should work: ... ... #elif defined(SPI_PINS_CSN9_CE8) #define CSN_PORT PORTB // port for CSN #define CSN_DDR DDRB // DDR for CSN #define CSN_PIN PB1 // Arduino Pin 9 <-> Bit 1 of port B #define CE_PORT PORTB // port for CE #define CE_DDR DDRB // DDR for CE #define CE_PIN PB0 // Arduino Pin 8 <-> Bit 0 of port B #endif and static void initSPI(void) { ... ... #elif defined(SPI_PINS_CSN9_CE8) // set pin mode: MOSI,SCLK,CE,CSN = OUTPUT, MISO = INPUT (=> all on same port) SPI_DDR = _BV(SPI_MOSI) | _BV(SPI_SCLK) | _BV(CE_PIN) | _BV(CSN_PIN) | ~_BV(SPI_MISO); #endif

@mfalkvidd Thanks for confirming about the BC message being normal protocol. I have used the log parser (great!) and the trouble shooting flowchart (great!). I am currently powering thru USB but as the comms problem is intermittend I need some further investigation.