Troubleshooting

@rejoe2 Thanks! I will do that. the code i used was from the examples. My relays work fine but my temp sensors never register. Even in serial. but if i run the Dallas temp my-sensors code separate i always get reading. Its just been mind boggling. :)

Great work @jimmy-loyens, thanks for sharing

Thanks and congratulations for the great site. I put a 10uF capacitor in parallel of both modules. Below the initial part of the sensor and then the total strings of the gateway (the gateway after these strings does not print any other data) Debug Sensor: 16 MCO:BGN:INIT NODE,CP=RNNNA---,REL=255,VER=2.3.1 26 TSM:INIT 27 TSF:WUR:MS=0 33 TSM:INIT:TSP OK 35 TSM:FPAR 37 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 2046 !TSM:FPAR:NO REPLY 2049 TSM:FPAR 2051 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 4058 !TSM:FPAR:NO REPLY 4060 TSM:FPAR 4062 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 6069 !TSM:FPAR:NO REPLY 6071 TSM:FPAR 6073 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 8080 !TSM:FPAR:FAIL 8081 TSM:FAIL:CNT=1 8083 TSM:FAIL:DIS 8085 TSF:TDI:TSL 18087 TSM:FAIL:RE-INIT 18089 TSM:INIT 18096 TSM:INIT:TSP OK 18098 TSM:FPAR 18100 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 20108 !TSM:FPAR:NO REPLY 20110 TSM:FPAR 20112 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 22120 !TSM:FPAR:NO REPLY Debug Gateway: Ž@lðhà,LJ¬ðCXа47 MCO:BGN:INIT GW,CP=RNNGE---,REL=255,VER=2.3.1 98 TSF:LRT:OK 113 TSM:INIT 127 TSF:WUR:MS=0 150 TSM:INIT:TSP OK scandone state: 0 -> 2 (b0) 200 TSM:INIT:GW MODE state: 2 -> 3 (0) state: 3 -> 5 (10) add 0 aid 7 cnt connected with NETGEAR, channel 3 dhcp client start... 337 TSM:READY:ID=0,PAR=0,DIS=0 370 MCO:REG:NOT NEEDED 396 TSM:READY:NWD REQ 2678 TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK: scandone 2762 GWT:TPC:CONNECTING... 3290 GWT:TPC:CONNECTING... 3818 GWT:TPC:CONNECTING... ip:192.168.0.63,mask:255.255.255.0,gw:192.168.0.1 4346 GWT:TPC:CONNECTING... 4374 GWT:TPC:IP=192.168.0.63 4405 MCO:BGN:STP 4423 MCO:BGN:INIT OK,TSP=1 4451 GWT:TPC:IP=192.168.0.63 4482 GWT:RMQ:MQTT RECONNECT 4541 GWT:RMQ:MQTT CONNECTED 4571 GWT:TPS:TOPIC=mygateway1-out/0/255/0/0/18,MSG SENT pm open,type:2 0

In my experience PIR sensor are very sensitive to spikes in the power supply, especially if you run them on voltages close to the lower limit. I feed mine with a separate +8 volt supply. If you run it on the same 5 volt supply as the ESP8266 you are almost guaranteed to get false triggers. The 20 seconds is probably the time after which the PIR resets. This causes a spike on the supply which triggers the PIR again. This happened to me.

@tekka said in NRF24L01 with Arduino Pro Mini at 1Mhz: @snyfir Can you run the same tests using the latest release, i.e. 2.3.1? It's working ! :man_dancing: :smiley: Thanks you very much @tekka and @mfalkvidd :+1:

Thank you mfalkvidd, I did it and it is working well now!. For those who want a simple solution and as future reference, here is my simple code: #define MY_DEBUG #define MY_BAUD_RATE 38400 #define MY_RADIO_NRF24 #define MY_RF24_PA_LEVEL RF24_PA_HIGH #define MY_RF24_CHANNEL 115 #define MY_RF24_DATARATE RF24_250KBPS #define MY_RF24_BASE_RADIO_ID 0x00,0xFC,0xE1,0xA8,0xA8 #define MY_NODE_ID 164 #include <SPI.h> #include <MySensors.h> #define RELAY_PIN 2 // Arduino Digital I/O pin number for first relay (second on pin+1 etc) #define NUMBER_OF_RELAYS 1 // Total number of attached relays #define RELAY_ON 1 // GPIO value to write to turn on attached relay #define RELAY_OFF 0 // GPIO value to write to turn off attached relay #define RELAY_CHILD_ID 1 // Id of the sensor child RELAY #define MOTION_CHILD_ID 2 // Id of the sensor child MOTION #define DIGITAL_INPUT_SENSOR 3 // The digital input you attached your motion sensor. (Only 2 and 3 generates interrupt!) uint32_t SLEEP_TIME = 10000; // Sleep time between reports (in milliseconds)..NOT USED ANYMORE BECAUSE IT TURNS OFF THE NODE AND IT CAN'T RECEIVE RELAY REMOTE TRIGGERING ORDER boolean lastMotion = false; // Initialize motion message MyMessage msg(MOTION_CHILD_ID, V_TRIPPED); void before() { for (int sensor=1, pin=RELAY_PIN; sensor<=NUMBER_OF_RELAYS; sensor++, pin++) { // Then set relay pins in output mode pinMode(pin, OUTPUT); //Always starts OFF digitalWrite(pin, RELAY_OFF); } pinMode(DIGITAL_INPUT_SENSOR, INPUT); // sets the motion sensor digital pin as input } void setup() { } void presentation() { // Send the sketch version information to the gateway and Controller sendSketchInfo("Relay_PLUS_PIR", "1.0"); for (int sensor=1, pin=RELAY_PIN; sensor<=NUMBER_OF_RELAYS; sensor++, pin++) { // Register all sensors to gw (they will be created as child devices) present(sensor, S_LIGHT); } // Register all sensors to gw (they will be created as child devices) present(MOTION_CHILD_ID, S_MOTION); } void loop() { // Read digital motion value bool motion = digitalRead(DIGITAL_INPUT_SENSOR) == HIGH; if (lastMotion != motion) { lastMotion = motion; Serial.println(motion); send(msg.set(motion?"1":"0")); // Send tripped value to gw } // Sleep until interrupt comes in on motion sensor. Send update every two minute. // NOT USED // sleep(digitalPinToInterrupt(DIGITAL_INPUT_SENSOR), CHANGE, SLEEP_TIME); // NOT USED } void receive(const MyMessage &message) { // We only expect one type of message from controller. But we better check anyway. if (message.type==V_LIGHT) { // Change relay state digitalWrite( RELAY_PIN, message.getBool()?RELAY_ON:RELAY_OFF); //digitalWrite(message.sensor-1+RELAY_PIN, message.getBool()?RELAY_ON:RELAY_OFF); // Store state in eeprom saveState(message.sensor, message.getBool()); // Write some debug info Serial.print("Incoming change for sensor:"); Serial.print(message.sensor); Serial.print(", New status: "); Serial.println(message.getBool()); } } Regards!

@hhn10 missing capacitor is the top reason for bad communication so your best bet is to wait for the capacitors to arrive. Welcome to the forum

@sunnyboy69 Getting false readings can be anything as it depends if it is a serial read from the device or simple timing of the echo, unstable voltage, or even an object caught in the path of quite a wide cone, but without further details it is impossible to identify. I've been caught before with a serial reading device, took a while before I realised.... An extension of what @bjacobse suggested is to repeat readings until you get two identical consecutive results which are <> known limits and not cuckoo results..

@zboblamont said in Multiple Dallas Temperatuur sensors at one sensor node: If you cannot daisy chain them because there is no sequential route between locations, use a separate pin for each data line (powered via resistor) and communicate with each line in turn. The line here is using 3 cores in 20-30m of Cat5e cable to ensure each chip is physically sequential on the line. When I added a further sensor location, a loop had to be spliced in to keep the line a daisy chain. It is a small house, the length is purely down to the route, and cable is cheap. in case you can not daisy chain them because there is no sequential direction among locations, use a separate pin for each data line (powered thru resistor) and talk with each line in flip. the road here is using three cores in 20-30m of Cat5e cable to make certain each chip is physically sequential on the road. after I delivered a similarly sensor vicinity, a loop needed to be spliced in to preserve the road a daisy chain. it is a small residence, the period is purely down to the route, and cable is cheap.

I think you're right and it has a dialogue with a very specific protocol, but maybe my injector is too sophisticated, and a simple injector like the one in the photo does not support a dialog protocol.

Is setup() also exiting correctly or only entering? If all this happens, add a one-time routine in loop().

I was hoping back then that Domoticz would get on the wagon and add support for these, but they never did. Unless they have done something recently, I haven't used Domoticz in a few years. It's good to know that there are others out there that do support this.

@willemx I don't understand all the details, but here is how I have understood the situation: MySensors needed to override some internal esp8266 functions to seamlessly (for the sketch developer) provide the same features that MySensors offers for other microcontrollers. The esp team changed those functions in the 2.4.2 release, which caused compile errors for sketch developers if they upgraded the board definitions. MySensors development version was modified to handle the new functions. By doing this, it was no longer possible to compile MySensors with the old (and still widely used, most people don't upgrade their board definitions) esp8266board definitions. So when a new release of MySensors is done, everyone who hasn't upgraded their board definition but have upgraded the MySensors library will be unable to compile their code. On the upside, everyone who has upgraded their board definitions will be able to compile without trouble. The only "safe" way (for future upgrades) is to remove important functionality, eliminating the need to override internal esp functions. But that will also get a lot of people into trouble. So what we've got is that whatever we do, people will get into trouble. There are no warnings in the esp8266 release notes because the esp team is not responsible for keeping compatibility with internal functions. There are no warnings in the MySensors release notes because the latest MySensors release was made before the esp8266 changes were present. There will be a note in the release notes for the next MySensors release.

@yveaux well that's just not going to work for me, I'm trying to cut down on the amount of power supplies and random junk I have spread all over the place.

Update: rebuild from the bones. Raspi-OS, Domoticz, Mosquitto, MySensors. I don´t get a version of my gateway nether. Sensors run but have to be renamed complete within Domotics (database backup did not help), and all data is lost.

@yakcrac try the download link in the top menu

@mfalkvidd I don't know i will try when the next release will get out