Troubleshooting

@tbowmo Thanks a lot. It is just that "Series" filter which is confusing me :) I am searching to know what it means because I find that all factors are the same except for this filter, and the price varies.

I tried and failed almost every procedure. But in my last atempt I plugged in an USBtinyISP to my new(old) arduino with 328p socket. After clicking burn bootloader it took like 2 sec then it said that the burning was colmplete. The only visual clue that anything has changed is that the default blink-sketch that blinks the built in led have stoped blinking on the UNO and is solid now. How can I test if everything is ok? I tried uploading the blink sketch again to the UNO and the upload took alot longer and I got this error: Board arduino:avr:apm96 doesn't define a 'build.board' preference. Auto-set to: AVR_APM96 But it all complied and uploaded correctly in the end and it started blinking again.

As stated in other threads, upgrading the gateway to latest dev version (2.x) solved the problem! Great, got the old mouse trap up and running again. :grin: https://youtu.be/v8gWVBEqwxc

Why the RF24_PA_LEVEL_GW by default is set to low?

To explain this: Normally the DTR line is pulled down to reset the arduino. After the reset the arduino starts the bootloader and accepts the serial upload. If the DTR line is broken you can manually reset the arduino, you just need the right timing.

You should probably try to use the MQTT client Gateway in the dev-branch. It forwards internal commands as well unlike the gateway in 1.5 which on do some forwards and rewrites of internal commands.

Yes, I agree with @mfalkvidd, and I also think we need a section in the API for what the s, c , t, pt etc means. Right now you can only figure that out by reading the source, or by asking in the forum. I wrote a post explaining those, a while back, but posts get lost in the flood of posts.

Wow, this was a lot of information at once :) I'm going to go through the code tomorrow and actually figure out whats going on. I'm contemplating actually writing my own code, instead of relying on someone else's. Might make things easier (or harder :P ) but in the end i think i might benefit from it. i changed the code i had with the changes you suggested, and i can see the messages coming through to the gateway, but i still can't actually get home-assistant to display them. Trying to figure out if it's the code on the sensor, the code on the gateway or somewhere in-between that the message gets lost. i really appreciate all your help, i'll get back as soon as i've revised my code and (knock on wood) got it to work :) Again, thanks for all the help!

Can you simply connect your baro sensor to relay node and see if something happens? Can you exchange hw/sw with the working (relay) node in any other way? Are both the working node and this one connecting to your repeater node 1 (parent = 1)?

yes, and with si7021 there is no delay, faster readings, i2c better, low power. I like it too :)

@hek said: @doblanch said: btw, you didn't answer my question, is there a trusted NRF/PA/LNA seller, I cannot make any guarantees. But ITead should sell the genuine thing. it was my assumption too ... If I enable debug, will it provide me more info about communication ?

does the same issue happen with the arduino blink example?

I am not familiar with FHEM, but I think you problem is in the FHEM settings - the controller is not assigning the ID to the sensor. Did you try to assign the node ID manually in gw.begin?

@benalsop ok never mind!! After trying the inclusion process about 8 more times it finally found the relay! Now both are included and it all works, whew, a little buggy but I'll take it as long as it continues to function...

:thumbsup:

I added a lot more debug output and find that it gets stuck in here: while( ! ( get_status() & ( _BV(TX_DS) | _BV(MAX_RT) ))) { #if defined (FAILURE_HANDLING) if(millis() - timer > 75){ errNotify();