Posts made by NickBuilder

@jocke4u, I really want my power node to work so I was going to try to make my own rule based on the "expert" strategy and the 999 node/child.

But first I tried an even simpler approach, I added a var1-item from the power thing and now I have communication between node and gateway. Please give it a try yourself and see if it works for you.

More specifically I defined the following item:
Number PulseVar "Var1 [%d]" { channel="mysensors:power:gateway:pulseThing:var1" }

Be sure to also persist the item. I store it in a mapdb dataset:
PulseVar : strategy = everyChange, restoreOnStartup

FYI, my thing is defined as follows:
power pulseThing [ nodeId=50, childId=1 ]

Please give it a try and come back with the outcome.

EDIT: this feels like a too simple fix, I suspect that @TimO has made some changes in the 2.3 snapshot...

@timo regarding the issue with the pulse power node, the same as @jocke4u. I'm using a version of the same sketch and also the latest snapshot jar.

This is the feedback in my openhab.log while looking att the debug level messages from the binding.

15:59:15.829 [WARN ] [ors.internal.gateway.MySensorsGateway] - Request received, but variable state is not yet defined
15:59:15.834 [DEBUG] [orsAbstractConnection$MySensorsReader] - Message from gateway received: 50;1;2;0;24;
15:59:15.839 [DEBUG] [ors.internal.gateway.MySensorsGateway] - Node 50 found in gateway
15:59:15.844 [DEBUG] [ors.internal.gateway.MySensorsGateway] - Child 1 found in node 50
15:59:15.849 [WARN ] [ors.internal.gateway.MySensorsGateway] - Request received, but variable state is not yet defined
15:59:15.854 [DEBUG] [orsAbstractConnection$MySensorsReader] - Message from gateway received: 50;1;2;0;24;
15:59:15.859 [DEBUG] [ors.internal.gateway.MySensorsGateway] - Node 50 found in gateway
15:59:15.864 [DEBUG] [ors.internal.gateway.MySensorsGateway] - Child 1 found in node 50
15:59:15.869 [WARN ] [ors.internal.gateway.MySensorsGateway] - Request received, but variable state is not yet defined
15:59:15.874 [DEBUG] [orsAbstractConnection$MySensorsReader] - Message from gateway received: 50;1;2;0;24;
15:59:15.879 [DEBUG] [ors.internal.gateway.MySensorsGateway] - Node 50 found in gateway

As you can see the messages are quite frequent making it quite tedious for me to extract the relevant log messages. I'm no expert in browsing and searching text files from the command line.

I guess because I'm using a version of the standard sketch my node does not wait for a response to the request before starting to count. I'm not sure how the node can neglect the response. Anyhow I restarted my node and now it tried to SET a new count instead.

2018-01-10 16:26:22.341 [DEBUG] [rsAbstractConnection$MySensorsWriter] - Sending to MySensors: 50;1;1;0;24;150
2018-01-10 16:26:22.571 [DEBUG] [rsAbstractConnection$MySensorsWriter] - Sending to MySensors: 50;1;1;0;24;150
2018-01-10 16:26:22.791 [DEBUG] [rsAbstractConnection$MySensorsWriter] - Sending to MySensors: 50;1;1;0;24;150
2018-01-10 16:26:23.011 [DEBUG] [rsAbstractConnection$MySensorsWriter] - Sending to MySensors: 50;1;1;0;24;150
2018-01-10 16:26:23.230 [DEBUG] [rsAbstractConnection$MySensorsWriter] - Sending to MySensors: 50;1;1;0;24;150

Hopefully this is useful feedback.

Thank you @scalz! That did the trick. Finally I can debug the code with readable serial feedback.

Ok @AWI so the example code is probably in need for some adjustments. Its kinda hard for a beginner like myself to learn the basics if also the example code suffers from questionable functionality. Or perhaps the functionality is ok but the code by itself is not clear enough to educate the masses.

I'm still having trouble understanding whats really happening when using the sleep() call. In my newest revision I'm not passing any interrupt conditions other than a time variable but still its obvious that the sleep is interrupted by the interrupt defined in the setup section. And as such, perhaps also some timer functionality is running while in a MySensors sleep.
Perhaps the API description is in need for some additional clarification.

Note: I've also deleted the attach and detach calls from the loop() section as this is probably handled by the sleep function (or other hidden code).

@Beat-Siegenthaler thanks for your effort, it didn't have any effect. The answer to my problems is somewhere in the response by AWI.

@AWI, somewhere around this problem is a big revelation for me regarding the MySensors library. As I said, I'm a beginner at this.

Answer me this, in the original power meter sketch there is the option to turn on sleep mode for the battery powered counter. You say that timers are off during deep sleep so this kind of sleep is not the "deep sleep" which you are referring to?

I guess there must be some strange thing with the above referenced sketch as for "sleep_mode = true" the "now counter" (millis() ) is expected to increase also during sleep (MySensors kind) but this is not happening as I have found out. What actually sleeps during sleep? How are timers and interrupts handled?

Am I missing some documentation here dealing with deviations from the underlying Aruino functionality? Perhaps the MySensors concept is more focused on users not wanting to fiddle that much with the sketches?

Hi!

I'm quite frustrated with this right now but I'm also well aware that I'm a beginner. The following problem is probably quite trivial to most of you.

I've adapted the power sensor code (pulse counter) so that its more suitable for my needs. I'm powering it from batteries so I've deleted everything dealing with the time aspects. As the sensor will be sleeping in between counts it makes no sense, the way I understand it, sleeping a given time or doing something based on time differences. Is the original code bad in this aspect? Wouldn't waking up only on a time condition mean that interrupts would be missed?

I've also deleted the request call for V_VAR1 from the original code as the OH2-binding doesn't allow this request to be answered in an easy way.

The code and the the serial output is attached below.

FIY:
Software: Arduino IDE 1.6.12, MySensors 2.0.0
Sensor hardware: Pro Mini 3V3 8MHz, amplified nRF24L01 ("dirty" foil shielding), Sundberg Newbie PCB Rev.8 (thank you!)
Controller: OH2b4 with serial GW.

Why is the serial output showing gibberish?
And why isn´t there a "detach" and a "attach" of the interrupt in the loop() in the original code? Is it only due to the fact that the pulses aren't assumed to be generated fast enough? I'm debugging the sensor using a quite fast blinking bike tail light.

Please help!

// Enable debug prints
#define MY_DEBUG
#define MY_DEBUG_LITE

#define MY_NODE_ID 50

// Enable and select radio type attached
#define MY_RADIO_NRF24
#define MY_RF24_PA_LEVEL RF24_PA_MAX
#define MY_BAUD_RATE  38400

#include <MySensors.h>  

#define DIGITAL_INPUT_SENSOR 3  // The digital input you attached your light sensor.  (Only 2 and 3 generates interrupt!)
#define PULSE_FACTOR 1000       // Nummber of blinks per KWH of your meeter
#define CHILD_ID 1              // Id of the sensor child
int BATTERY_SENSE_PIN = A0;     // select the input pin for the battery sense point

double ppwh = ((double)PULSE_FACTOR)/1000; // Pulses per watt hour

volatile unsigned long pulseCount = 0; // volatile as its dealt with within an interrupt
unsigned long oldPulseCount = 0;
unsigned long countDiff = 0;   
double oldKwh;

int oldBatteryPcnt = 150; // a fresh battery has ~102 % charge, 150 makes the charge difference positive

MyMessage kwhMsg(CHILD_ID,V_KWH); 
MyMessage pcMsg(CHILD_ID,V_WATT); // using V_WATT for pulsecount data, V_VAR1 is not included in OH2-binding power thing

void setup() {  
  
  // Use the internal pullup to be able to hook up this sketch directly to an energy meter with S0 output
  // If no pullup is used, the reported usage will be too high because of the floating pin
  pinMode(DIGITAL_INPUT_SENSOR,INPUT_PULLUP);

  attachInterrupt(digitalPinToInterrupt(DIGITAL_INPUT_SENSOR), onPulse, RISING);
  
  // use the 1.1 V internal reference
  #if defined(__AVR_ATmega2560__)
    analogReference(INTERNAL1V1);
  #else
    analogReference(INTERNAL); //INTERNAL
  #endif    
}// setup

void presentation() {
  // Send the sketch version information to the gateway and Controller
  sendSketchInfo("Energy Meter - kWh", "2.0");

  // Register this device as power sensor
  present(CHILD_ID, S_POWER,"PulseCounter", 0);
  
}// presentation

void loop() {   

  // detach as we are working with a volatile variable
  detachInterrupt(digitalPinToInterrupt(DIGITAL_INPUT_SENSOR));
  
  countDiff = pulseCount-oldPulseCount;

  #ifdef MY_DEBUG_LITE
    Serial.print("pulseCount: ");
    Serial.print(pulseCount);
    Serial.print(" oldPulseCount: ");
    Serial.print(oldPulseCount);    
    Serial.print(" countDiff: ");       
    Serial.println(countDiff);
  #endif    

  // Power up radio after enough counts, here > 150 Wh
  if (countDiff >= 150) {
    send(pcMsg.set(pulseCount), 0);  // Send pulse count value to gw

    #ifdef MY_DEBUG_LITE
      Serial.print("pc: ");
      Serial.println(pulseCount);
    #endif
      
    double kwh = ((double)pulseCount/((double)PULSE_FACTOR));     
    oldPulseCount = pulseCount;
    if (kwh != oldKwh) {
      send(kwhMsg.set(kwh, 4), 0);  // Send kwh value to gw 
      oldKwh = kwh;
             
      #ifdef MY_DEBUG_LITE
        Serial.print("kWh: ");
        Serial.println(kwh);        
      #endif

      sendBatt();        
    }// kwh != oldKwh             
  }// countDiff >= 150                   

  attachInterrupt(digitalPinToInterrupt(DIGITAL_INPUT_SENSOR), onPulse, RISING);  
  // sleep, wake only on interrupt
  sleep(digitalPinToInterrupt(DIGITAL_INPUT_SENSOR), RISING, 0); 
    
}// loop


void sendBatt(void) {

  // get the battery Voltage
  int sensorValue = analogRead(BATTERY_SENSE_PIN);
 
  // 1M, 470K divider across battery and using internal ADC ref of 1.1V
  // Sense point is bypassed with 0.1 uF cap to reduce noise at that point
  // ((1e6+470e3)/470e3)*1.1 = Vmax = 3.44 Volts
  // 3.44/1023 = Volts per bit = 0.003363075

  int batteryPcnt = sensorValue / 10;  

  if (oldBatteryPcnt != batteryPcnt) {
    int batteryDiff = oldBatteryPcnt-batteryPcnt;    
    
    if (batteryDiff >= 1) {
      // Power up radio after sleep
      sendBatteryLevel(batteryPcnt, 0);
      oldBatteryPcnt = batteryPcnt;  
    }// batteryDiff >= 1               
  }// oldBatteryPcnt != batteryPcnt
  
}// sendBatt

void onPulse() {    
  pulseCount++;
}// onPulse

Starting sensor (RNNNA-, 2.0.0)
TSM:INIT
TSM:RADIO:OK
TSP:ASSIGNID:OK (ID=50)
TSM:FPAR
TSP:MSG:SEND 50-50-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSP:MSG:READ 0-0-50 s=255,c=3,t=8,pt=1,l=1,sg=0:0
TSP:MSG:FPAR RES (ID=0, dist=0)
TSP:MSG:PAR OK (ID=0, dist=1)
TSM:FPAR:OK
TSM:ID
TSM:CHKID:OK (ID=50)
TSM:UPL
TSP:PING:SEND (dest=0)
!TSP:MSG:SEND 50-50-0-0 s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=fail:1
TSP:MSG:READ 0-0-50 s=255,c=3,t=25,pt=1,l=1,sg=0:1
TSP:MSG:PONG RECV (hops=1)
TSP:CHKUPL:OK
TSM:UPL:OK
TSM:READY
!TSP:MSG:SEND 50-50-0-0 s=255,c=3,t=15,pt=6,l=2,sg=0,ft=1,st=fail:0100
TSP:MSG:SEND 50-50-0-0 s=255,c=0,t=17,pt=0,l=5,sg=0,ft=2,st=ok:2.0.0
TSP:MSG:SEND 50-50-0-0 s=255,c=3,t=6,pt=1,l=1,sg=0,ft=0,st=ok:0
TSP:MSG:SEND 50-50-0-0 s=255,c=3,t=11,pt=0,l=18,sg=0,ft=0,st=ok:Energy Meter - kWh
TSP:MSG:SEND 50-50-0-0 s=255,c=3,t=12,pt=0,l=3,sg=0,ft=0,st=ok:2.0
TSP:MSG:SEND 50-50-0-0 s=1,c=0,t=13,pt=0,l=12,sg=0,ft=0,st=ok:PulseCounter
Request registration...
!TSP:MSG:SEND 50-50-0-0 s=255,c=3,t=26,pt=1,l=1,sg=0,ft=0,st=fail:2
!TSP:MSG:SEND 50-50-0-0 s=255,c=3,t=26,pt=1,l=1,sg=0,ft=1,st=fail:2
!TSP:MSG:SEND 50-50-0-0 s=255,c=3,t=26,pt=1,l=1,sg=0,ft=2,st=fail:2
!TSP:MSG:SEND 50-50-0-0 s=255,c=3,t=26,pt=1,l=1,sg=0,ft=3,st=fail:2
Init complete, id=50, parent=0, distance=1, registration=1
pulsY¨«—‹—‚z±‘Aձ͕½Õù‹—‚½Õ¹Ñ¥™™é‚j¤ձ͕½Õ¹Ñé‚z±‘Aձ͕½Õù‹—‚½Õ¹Ñ¥™™é‚j¤ձ͕½Õ¹Ñé‚z±‘Aձ͕½Õù‹—‚½Õ¹Ñ¥™™é‚j¤ձ͕½  [....]

@Alexandre-Magno

Hi!

Look here: https://www.arduino.cc/en/Main/ArduinoBoardProMini
Check the documentation/schematics section.

Hi @AWI!

The GIT link is broken. Can I find your sketch for this counter elsewhere?

I would like to implement this counter as a "local sensor" on an ethernet gateway without radio. I guess this would require some tweaking but right now I'm confident. x)

Thanks!

@AWI, thanks to your sketch and the concept of transmission quality measurement I did some adjustments to my setup.

I guess the most critical reason for the bad numbers shown on the meter for my network was due to a poor gateway. After applying the cheep and dirty EMI fix, a ground connected foil, and playing around with the transceiver power I finally got some good numbers on the meter.

So now I've placed a post-it on each module indicating a sort of long term fail average. A couple of them shows quite poor fail/miss values, 60-80 %. The best ones reaches around 5-15 % but this could be due to the gateway radio.

Actually I still don't know if the gateway transceiver is optimized. I should test some additional radio units.

Using large caps for the radio is recommended. There's no reason why not to use a bigger cap, > x00 uF. The ones rated for lower voltages are quite small in physical terms.

Thank you for this @AWI!

@AWI, it's hardly visible but I'm actually using a 3V3 buck and a 10 uF cap to power the radio. But I took your advice and tried tos power the radio seperately with two AA batterys, and a cap just in case. This should be a really clean source of power but the outcome is still the same.

I guess I'll order som new radios, hopefully from a different supplier. I'll get some adapter boards with (switchless) LDO's while I'm at it.

Why is the parent changing from 255 to 0 back and forth? I have a serial gateway connected to a Pi and aside from some temp sensors I also have an RC switch for my outlets which also acts as a gateway but the adress is neither 255 nor 0.

Thanks!

Great tool for a mysensors builder @AWI! I also want to sort out the good radios from the bad, I have enough trouble as it is trying to troubleshoot my questionable sensors.

I got around to building a quality meter for myself, although without the adapter board and with some additional differences. But I really don't understand the output, the fail and miss percentage is almost always 100 % for most of my radios. Am I missing something? Perhaps I should change some addresses to static ones? I thought that perhaps I had to define a corresponding item in Openhab in order for the packages to be acknowledged but this doesn't change the outcome.

Here's the serial output from the "quality meter":

Starting sensor (RNNNA-, 2.0.0)
TSM:INIT
TSM:RADIO:OK
TSP:ASSIGNID:OK (ID=250)
TSM:FPAR
TSP:MSG:SEND 250-250-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSP:MSG:READ 0-0-250 s=255,c=3,t=8,pt=1,l=1,sg=0:0
TSP:MSG:FPAR RES (ID=0, dist=0)
TSP:MSG:PAR OK (ID=0, dist=1)
TSM:FPAR:OK
TSM:ID
TSM:CHKID:OK (ID=250)
TSM:UPL
TSP:PING:SEND (dest=0)
!TSP:MSG:SEND 250-250-0-0 s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=fail:1
TSP:MSG:READ 0-0-250 s=255,c=3,t=25,pt=1,l=1,sg=0:1
TSP:MSG:PONG RECV (hops=1)
TSP:CHKUPL:OK
TSM:UPL:OK
TSM:READY
!TSP:MSG:SEND 250-250-0-0 s=255,c=3,t=15,pt=6,l=2,sg=0,ft=1,st=fail:0100
!TSP:MSG:SEND 250-250-0-0 s=255,c=0,t=17,pt=0,l=5,sg=0,ft=2,st=fail:2.0.0
!TSP:MSG:SEND 250-250-0-0 s=255,c=3,t=6,pt=1,l=1,sg=0,ft=3,st=fail:0
TSP:MSG:READ 0-0-250 s=255,c=3,t=6,pt=0,l=1,sg=0:M
!TSP:MSG:SEND 250-250-0-0 s=0,c=0,t=4,pt=0,l=21,sg=0,ft=4,st=fail:Quality counter Q 250
Request registration...
!TSP:MSG:SEND 250-250-0-0 s=255,c=3,t=26,pt=1,l=1,sg=0,ft=5,st=fail:2
!TSM:UPL FAIL, SNP
TSM:FPAR
TSP:MSG:SEND 250-250-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
!TSP:SEND:TNR
TSM:FPAR
TSP:MSG:SEND 250-250-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSP:MSG:READ 0-0-250 s=255,c=3,t=8,pt=1,l=1,sg=0:0
TSP:MSG:FPAR RES (ID=0, dist=0)
TSP:MSG:PAR OK (ID=0, dist=1)
!TSP:SEND:TNR
TSM:FPAR:OK
TSM:ID
TSM:CHKID:OK (ID=250)
TSM:UPL
TSP:PING:SEND (dest=0)
!TSP:MSG:SEND 250-250-0-0 s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=fail:1
TSP:MSG:READ 0-0-250 s=255,c=3,t=25,pt=1,l=1,sg=0:1
TSP:MSG:PONG RECV (hops=1)
TSP:CHKUPL:OK
TSM:UPL:OK
TSM:READY
!TSP:MSG:SEND 250-250-0-0 s=255,c=3,t=26,pt=1,l=1,sg=0,ft=1,st=fail:2
TSP:MSG:READ 0-0-250 s=255,c=3,t=27,pt=1,l=1,sg=0:1
Node registration=1
Init complete, id=250, parent=0, distance=1, registration=1
!TSP:MSG:SEND 250-250-0-0 s=0,c=1,t=3,pt=2,l=2,sg=0,ft=2,st=fail:0
Fail on message: 0 # 1
TSP:MSG:READ 0-0-250 s=0,c=1,t=3,pt=2,l=2,sg=0:0
Missed messages: 0
!TSP:MSG:SEND 250-250-0-0 s=0,c=1,t=3,pt=2,l=2,sg=0,ft=3,st=fail:1
Fail on message: 1 # 2
!TSP:MSG:SEND 250-250-0-0 s=0,c=1,t=3,pt=2,l=2,sg=0,ft=4,st=fail:2
Fail on message: 2 # 3
!TSP:MSG:SEND 250-250-0-0 s=0,c=1,t=3,pt=2,l=2,sg=0,ft=5,st=fail:3
Fail on message: 3 # 4
!TSM:UPL FAIL, SNP
TSM:FPAR
TSP:MSG:SEND 250-250-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSP:MSG:READ 0-0-250 s=0,c=1,t=3,pt=2,l=2,sg=0:3
Missed messages: 2
!TSP:SEND:TNR
Fail on message: 4 # 5
!TSP:SEND:TNR
Fail on message: 5 # 6
!TSP:SEND:TNR
Fail on message: 6 # 7
!TSP:SEND:TNR
Fail on message: 7 # 8
TSM:FPAR
TSP:MSG:SEND 250-250-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSP:MSG:READ 0-0-250 s=255,c=3,t=8,pt=1,l=1,sg=0:0
TSP:MSG:FPAR RES (ID=0, dist=0)
TSP:MSG:PAR OK (ID=0, dist=1)
!TSP:SEND:TNR
Fail on message: 8 # 9
!TSP:SEND:TNR
Fail on message: 9 # 10
!TSP:SEND:TNR
Fail on message: 10 # 11
TSM:FPAR:OK
TSM:ID
TSM:CHKID:OK (ID=250)
TSM:UPL
TSP:PING:SEND (dest=0)
!TSP:MSG:SEND 250-250-0-0 s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=fail:1
TSP:MSG:READ 0-0-250 s=255,c=3,t=25,pt=1,l=1,sg=0:1
TSP:MSG:PONG RECV (hops=1)
TSP:CHKUPL:OK
TSM:UPL:OK
TSM:READY
!TSP:MSG:SEND 250-250-0-0 s=0,c=1,t=3,pt=2,l=2,sg=0,ft=1,st=fail:11
Fail on message: 11 # 12
TSP:MSG:READ 0-0-250 s=0,c=1,t=3,pt=2,l=2,sg=0:11
Missed messages: 7
!TSP:MSG:SEND 250-250-0-0 s=0,c=1,t=3,pt=2,l=2,sg=0,ft=2,st=fail:12
Fail on message: 12 # 13
!TSP:MSG:SEND 250-250-0-0 s=0,c=1,t=3,pt=2,l=2,sg=0,ft=3,st=fail:13
Fail on message: 13 # 14
!TSP:MSG:SEND 250-250-0-0 s=0,c=1,t=3,pt=2,l=2,sg=0,ft=4,st=fail:14
Fail on message: 14 # 15
!TSP:MSG:SEND 250-250-0-0 s=0,c=1,t=3,pt=2,l=2,sg=0,ft=5,st=fail:15
Fail on message: 15 # 16
!TSM:UPL FAIL, SNP
TSM:FPAR
TSP:MSG:SEND 250-250-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
!TSP:SEND:TNR
Fail on message: 16 # 17
TSP:MSG:READ 0-0-250 s=255,c=3,t=8,pt=1,l=1,sg=0:0
TSP:MSG:FPAR RES (ID=0, dist=0)
TSP:MSG:PAR OK (ID=0, dist=1)
!TSP:SEND:TNR
Fail on message: 17 # 18
!TSP:SEND:TNR
Fail on message: 18 # 19
!TSP:SEND:TNR
Fail on message: 19 # 20
TSM:FPAR:OK
TSM:ID
TSM:CHKID:OK (ID=250)
TSM:UPL
TSP:PING:SEND (dest=0)
!TSP:MSG:SEND 250-250-0-0 s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=fail:1
TSP:CHKUPL:FAIL (hops=255)
!TSM:UPL:FAIL
TSM:FPAR
TSP:MSG:SEND 250-250-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
!TSP:SEND:TNR
Fail on message: 20 # 21
!TSP:SEND:TNR
Fail on message: 21 # 22
!TSP:SEND:TNR
Fail on message: 22 # 23
!TSP:SEND:TNR
Fail on message: 23 # 24
TSM:FPAR
TSP:MSG:SEND 250-250-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
!TSP:SEND:TNR
Fail on message: 24 # 25
!TSP:SEND:TNR
Fail on message: 25 # 26
TSP:MSG:READ 0-0-250 s=255,c=3,t=8,pt=1,l=1,sg=0:0
TSP:MSG:FPAR RES (ID=0, dist=0)
TSP:MSG:PAR OK (ID=0, dist=1)
!TSP:SEND:TNR
Fail on message: 26 # 27
!TSP:SEND:TNR
Fail on message: 27 # 28
TSM:FPAR:OK
TSM:ID
TSM:CHKID:OK (ID=250)
TSM:UPL
TSP:PING:SEND (dest=0)
!TSP:MSG:SEND 250-250-0-0 s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=fail:1
TSP:CHKUPL:FAIL (hops=255)
!TSM:UPL:FAIL
TSM:FPAR
TSP:MSG:SEND 250-250-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
!TSP:SEND:TNR
Fail on message: 28 # 29
!TSP:SEND:TNR
Fail on message: 29 # 30
!TSP:SEND:TNR
Fail on message: 30 # 31
!TSP:SEND:TNR
Fail on message: 31 # 32
TSM:FPAR
TSP:MSG:SEND 250-250-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
!TSP:SEND:TNR
Fail on message: 32 # 33
!TSP:SEND:TNR
Fail on message: 33 # 34
TSP:MSG:READ 0-0-250 s=255,c=3,t=8,pt=1,l=1,sg=0:0
TSP:MSG:FPAR RES (ID=0, dist=0)
TSP:MSG:PAR OK (ID=0, dist=1)
!TSP:SEND:TNR
Fail on message: 34 # 35
!TSP:SEND:TNR
Fail on message: 35 # 36
TSM:FPAR:OK
TSM:ID
TSM:CHKID:OK (ID=250)
TSM:UPL
TSP:PING:SEND (dest=0)
!TSP:MSG:SEND 250-250-0-0 s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=fail:1
TSP:MSG:READ 0-0-250 s=255,c=3,t=25,pt=1,l=1,sg=0:1
TSP:MSG:PONG RECV (hops=1)
TSP:CHKUPL:OK
TSM:UPL:OK
TSM:READY
!TSP:MSG:SEND 250-250-0-0 s=0,c=1,t=3,pt=2,l=2,sg=0,ft=1,st=fail:36
Fail on message: 36 # 37
!TSP:MSG:SEND 250-250-0-0 s=0,c=1,t=3,pt=2,l=2,sg=0,ft=2,st=fail:37
Fail on message: 37 # 38
TSP:MSG:READ 0-0-250 s=0,c=1,t=3,pt=2,l=2,sg=0:37
Missed messages: 25
!TSP:MSG:SEND 250-250-0-0 s=0,c=1,t=3,pt=2,l=2,sg=0,ft=3,st=fail:38
Fail on message: 38 # 39
TSP:MSG:READ 0-0-250 s=0,c=1,t=3,pt=2,l=2,sg=0:38
Missed messages: 0
!TSP:MSG:SEND 250-250-0-0 s=0,c=1,t=3,pt=2,l=2,sg=0,ft=4,st=fail:39
Fail on message: 39 # 40
TSP:MSG:READ 0-0-250 s=0,c=1,t=3,pt=2,l=2,sg=0:39
Missed messages: 0
!TSP:MSG:SEND 250-250-0-0 s=0,c=1,t=3,pt=2,l=2,sg=0,ft=5,st=fail:40
Fail on message: 40 # 41
!TSM:UPL FAIL, SNP
TSM:FPAR
TSP:MSG:SEND 250-250-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSP:MSG:READ 0-0-250 s=0,c=1,t=3,pt=2,l=2,sg=0:40
Missed messages: 0
!TSP:SEND:TNR
Fail on message: 41 # 42
TSP:MSG:READ 0-0-250 s=255,c=3,t=8,pt=1,l=1,sg=0:0
TSP:MSG:FPAR RES (ID=0, dist=0)
TSP:MSG:PAR OK (ID=0, dist=1)
!TSP:SEND:TNR
Fail on message: 42 # 43
!TSP:SEND:TNR
Fail on message: 43 # 44
TSM:FPAR:OK
TSM:ID
!TSP:SEND:TNR
Fail on message: 44 # 45
TSM:CHKID:OK (ID=250)
TSM:UPL
TSP:PING:SEND (dest=0)
!TSP:MSG:SEND 250-250-0-0 s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=fail:1
TSP:MSG:READ 0-0-250 s=255,c=3,t=25,pt=1,l=1,sg=0:1
TSP:MSG:PONG RECV (hops=1)
TSP:CHKUPL:OK
TSM:UPL:OK
TSM:READY
!TSP:MSG:SEND 250-250-0-0 s=0,c=1,t=3,pt=2,l=2,sg=0,ft=1,st=fail:45
Fail on message: 45 # 46
TSP:MSG:READ 0-0-250 s=0,c=1,t=3,pt=2,l=2,sg=0:45
Missed messages: 4
!TSP:MSG:SEND 250-250-0-0 s=0,c=1,t=3,pt=2,l=2,sg=0,ft=2,st=fail:46
Fail on message: 46 # 47
!TSP:MSG:SEND 250-250-0-0 s=0,c=1,t=3,pt=2,l=2,sg=0,ft=3,st=fail:47
Fail on message: 47 # 48
TSP:MSG:READ 0-0-250 s=0,c=1,t=3,pt=2,l=2,sg=0:47
Missed messages: 1
!TSP:MSG:SEND 250-250-0-0 s=0,c=1,t=3,pt=2,l=2,sg=0,ft=4,st=fail:48
Fail on message: 48 # 49
TSP:MSG:READ 0-0-250 s=0,c=1,t=3,pt=2,l=2,sg=0:48
Missed messages: 0
!TSP:MSG:SEND 250-250-0-0 s=0,c=1,t=3,pt=2,l=2,sg=0,ft=5,st=fail:49
Fail on message: 49 # 50
!TSM:UPL FAIL, SNP
TSM:FPAR
TSP:MSG:SEND 250-250-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
!TSP:SEND:TNR
Fail on message: 50 # 51
!TSP:SEND:TNR
Fail on message: 51 # 52
!TSP:SEND:TNR
Fail on message: 52 # 53
!TSP:SEND:TNR
Fail on message: 53 # 54
TSM:FPAR
TSP:MSG:SEND 250-250-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
!TSP:SEND:TNR
Fail on message: 54 # 55
TSP:MSG:READ 0-0-250 s=255,c=3,t=8,pt=1,l=1,sg=0:0
TSP:MSG:FPAR RES (ID=0, dist=0)
TSP:MSG:PAR OK (ID=0, dist=1)
!TSP:SEND:TNR
Fail on message: 55 # 56
!TSP:SEND:TNR
Fail on message: 56 # 57
TSM:FPAR:OK
TSM:ID
TSM:CHKID:OK (ID=250)
TSM:UPL
TSP:PING:SEND (dest=0)
!TSP:MSG:SEND 250-250-0-0 s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=fail:1
TSP:CHKUPL:FAIL (hops=255)
!TSM:UPL:FAIL
TSM:FPAR
TSP:MSG:SEND 250-250-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
!TSP:SEND:TNR
Fail on message: 57 # 58
!TSP:SEND:TNR
Fail on message: 58 # 59
!TSP:SEND:TNR
Fail on message: 59 # 60
!TSP:SEND:TNR
Fail on message: 60 # 61
TSM:FPAR
TSP:MSG:SEND 250-250-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
!TSP:SEND:TNR
Fail on message: 61 # 62
!TSP:SEND:TNR
Fail on message: 62 # 63
TSP:MSG:READ 0-0-250 s=255,c=3,t=8,pt=1,l=1,sg=0:0
TSP:MSG:FPAR RES (ID=0, dist=0)
TSP:MSG:PAR OK (ID=0, dist=1)
!TSP:SEND:TNR
Fail on message: 63 # 64
!TSP:SEND:TNR
Fail on message: 64 # 65
TSM:FPAR:OK
TSM:ID
TSM:CHKID:OK (ID=250)
TSM:UPL
TSP:PING:SEND (dest=0)
!TSP:MSG:SEND 250-250-0-0 s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=fail:1
TSP:CHKUPL:FAIL (hops=255)
!TSM:UPL:FAIL
TSM:FPAR
TSP:MSG:SEND 250-250-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
!TSP:SEND:TNR
Fail on message: 65 # 66
!TSP:SEND:TNR
Fail on message: 66 # 67
!TSP:SEND:TNR
Fail on message: 67 # 68
!TSP:SEND:TNR
Fail on message: 68 # 69
TSM:FPAR
TSP:MSG:SEND 250-250-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
!TSP:SEND:TNR
Fail on message: 69 # 70
!TSP:SEND:TNR
Fail on message: 70 # 71
TSP:MSG:READ 0-0-250 s=255,c=3,t=8,pt=1,l=1,sg=0:0
TSP:MSG:FPAR RES (ID=0, dist=0)
TSP:MSG:PAR OK (ID=0, dist=1)
!TSP:SEND:TNR
Fail on message: 71 # 72
!TSP:SEND:TNR
Fail on message: 72 # 73
TSM:FPAR:OK
TSM:ID
TSM:CHKID:OK (ID=250)
TSM:UPL
TSP:PING:SEND (dest=0)
!TSP:MSG:SEND 250-250-0-0 s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=fail:1
TSP:CHKUPL:FAIL (hops=255)
!TSM:UPL:FAIL
TSM:FPAR
TSP:MSG:SEND 250-250-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
!TSP:SEND:TNR
Fail on message: 73 # 74
!TSP:SEND:TNR
Fail on message: 74 # 75
!TSP:SEND:TNR
Fail on message: 75 # 76
!TSP:SEND:TNR
Fail on message: 76 # 77
TSM:FPAR
TSP:MSG:SEND 250-250-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
!TSP:SEND:TNR
Fail on message: 77 # 78
!TSP:SEND:TNR
Fail on message: 78 # 79
TSP:MSG:READ 0-0-250 s=255,c=3,t=8,pt=1,l=1,sg=0:0
TSP:MSG:FPAR RES (ID=0, dist=0)
TSP:MSG:PAR OK (ID=0, dist=1)
!TSP:SEND:TNR
Fail on message: 79 # 80
!TSP:SEND:TNR
Fail on message: 80 # 81
TSM:FPAR:OK
TSM:ID
TSM:CHKID:OK (ID=250)
TSM:UPL
TSP:PING:SEND (dest=0)
!TSP:MSG:SEND 250-250-0-0 s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=fail:1
TSP:CHKUPL:FAIL (hops=255)
!TSM:UPL:FAIL
TSM:FPAR
TSP:MSG:SEND 250-250-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
!TSP:SEND:TNR
Fail on message: 81 # 82
!TSP:SEND:TNR
Fail on message: 82 # 83
!TSP:SEND:TNR
Fail on message: 83 # 84
!TSP:SEND:TNR
Fail on message: 84 # 85
TSM:FPAR
TSP:MSG:SEND 250-250-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
!TSP:SEND:TNR
Fail on message: 85 # 86
!TSP:SEND:TNR
Fail on message: 86 # 87
TSP:MSG:READ 0-0-250 s=255,c=3,t=8,pt=1,l=1,sg=0:0
TSP:MSG:FPAR RES (ID=0, dist=0)
TSP:MSG:PAR OK (ID=0, dist=1)
!TSP:SEND:TNR
Fail on message: 87 # 88
!TSP:SEND:TNR
Fail on message: 88 # 89
TSM:FPAR:OK
TSM:ID
TSM:CHKID:OK (ID=250)
TSM:UPL
TSP:PING:SEND (dest=0)
TSP:MSG:SEND 250-250-0-0 s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=ok:1
TSP:MSG:READ 99-99-0 s=0,c=1,t=1,pt=7,l=5,sg=0:62.2
!TSM:MSG:REL MSG, but not a repeater
TSP:MSG:READ 0-0-250 s=255,c=3,t=25,pt=1,l=1,sg=0:1
TSP:MSG:PONG RECV (hops=1)
TSP:CHKUPL:OK
TSM:UPL:OK
TSM:READY
!TSP:MSG:SEND 250-250-0-0 s=0,c=1,t=3,pt=2,l=2,sg=0,ft=0,st=fail:89
Fail on message: 89 # 90
!TSP:MSG:SEND 250-250-0-0 s=0,c=1,t=3,pt=2,l=2,sg=0,ft=1,st=fail:90
Fail on message: 90 # 91
!TSP:MSG:SEND 250-250-0-0 s=0,c=1,t=3,pt=2,l=2,sg=0,ft=2,st=fail:91
Fail on message: 91 # 92
!TSP:MSG:SEND 250-250-0-0 s=0,c=1,t=3,pt=2,l=2,sg=0,ft=3,st=fail:92
Fail on message: 92 # 93
TSP:MSG:READ 0-0-250 s=0,c=1,t=3,pt=2,l=2,sg=0:92
Missed messages: 43
!TSP:MSG:SEND 250-250-0-0 s=0,c=1,t=3,pt=2,l=2,sg=0,ft=4,st=fail:93
Fail on message: 93 # 94
TSP:MSG:READ 0-0-250 s=0,c=1,t=3,pt=2,l=2,sg=0:93
Missed messages: 0
!TSP:MSG:SEND 250-250-0-0 s=0,c=1,t=3,pt=2,l=2,sg=0,ft=5,st=fail:94
Fail on message: 94 # 95
!TSM:UPL FAIL, SNP
TSM:FPAR
TSP:MSG:SEND 250-250-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSP:MSG:READ 0-0-250 s=0,c=1,t=3,pt=2,l=2,sg=0:94
Missed messages: 0
TSP:MSG:READ 0-0-250 s=255,c=3,t=8,pt=1,l=1,sg=0:0
TSP:MSG:FPAR RES (ID=0, dist=0)
TSP:MSG:PAR OK (ID=0, dist=1)
!TSP:SEND:TNR
Fail on message: 95 # 96
!TSP:SEND:TNR
Fail on message: 96 # 97
!TSP:SEND:TNR
Fail on message: 97 # 98
!TSP:SEND:TNR
Fail on message: 98 # 99
TSM:FPAR:OK
TSM:ID
TSM:CHKID:OK (ID=250)
TSM:UPL
TSP:PING:SEND (dest=0)
!TSP:MSG:SEND 250-250-0-0 s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=fail:1

Also, the meter in action generating the output above can be seen here: LINK
After some time, >10 min, the fail percentage is 100 % and the miss percentage around 85 %. Not impressive if interpreted correctly. Could someone give me some pointers to what the problem is? I don't talk "mysensors protocol".

Sorry @siod, I don't think I can help you. You seem to get a lot more messages through though.

@bkl
Ok. But for some reason the new value is not accepted in my case. I will try and see if the serial terminal, when connected to the sensor, will give a hint on what’s going on. It would be nice if the debug of the binding could show what is actually being sent to (and possibly through) the gateway. Is this possible already by ”activating” a certain debug.xml module?

The serial binding is quite clear in this regard as the message with payload according to the mysensor protocol is displayed in the debug log.

@sensorchecker Hi!
Its not easy helping you using only the posted information. Any debug logs available from Openhab or the serial interface terminal?

My item defintion looks the same:

Switch Lampa <light> {mysensors="40;1;V_STATUS"}

Hi @bkl and all other user of this great binding!

I would like to know if its possible to send a message using this binding. I will try to explain my problem.

I've built the "EnergyMeterPulseSensor.ino" sensor and I have it up and running. The sketch request a starting number for the count loop and if the item in Openhab has been initialized this value is sent back per request.
This request function is only active before the actual count begins.

I would now like to be able to reset the counter each midnight but as the sensor only requests the start count value at each startup I would have to manually restart the sensor at the same time as I have "reinitialized" the count item with a "0".

I now see two ways of doing this if this binding allows it:

• 1: Send a "I_REBOOT" in some way through the binding directly after manually updating the count item with a "0".

• 2: Sending a new count value via the V_VAR1 parameter. This would be preferable I guess.

In this thread @stoffej is after the same thing. I've tried the same approach using a myPulsecountItem.sendCommand(0) but other than adding a "0" to the persistence service nothing happens. The count continues where it left off. So my guess is that there is no actual message sent to the sensor. Sadly I don't get any useful information from the debug-xml. I don't know where @stoffej got the debug message I_LOG_MESSAGE:..., my serial debugging interface towards the gateway is occupied.

My count item is defined as:

Number  myElecVar "Elmätare pulser [%d]" {mysensors="50;1;V_VAR1"}

I guess if I could utilize a switch item in some way I could send a message in the same way as in the relay implementation. For a switch I know that a message is being sent as I've built one of those myself but the switch can only send "on" or "off".

Here's the receive function from the sketch:

void receive(const MyMessage &message) {
  if (message.type==V_VAR1) {  
    pulseCount = oldPulseCount = message.getLong();
    Serial.print("Received last pulse count from gw:");
    Serial.println(pulseCount);
    pcReceived = true;
  }
}

Assistance is much appreciated!

This has been solved!

Hi @stoffej!

Can you please try to assist me on a very similar topic?

I've built the EnergyMeterPulseSensor.ino pulse count sensor from the 2.0 library but I'm unable to initialize the items and I'm quite certain that this is why I'm not getting any values into Openhab. The Arduino is waiting for a request to be acknowledged which I guess is not happening.

I have enabled persistence for the pulse counter items and I've also tried to initialize the items by manually sending a value through the openhab console (telnet localhost 5555). After updating the values manually I can see the new value in the sitemap-GUI but the actual counting does not start.

After restarting Openhab the following is shown in the log:

... - New Item "myPCVar (Type=NumberItem, state=Uninitialized) based on configuration "50;1;V_VAR1"

A funny thing is that I actually got it working while working on the pulse counter on an experimental setup without actually trying to initialize the items. I don't know what I did at that time or if it started working just by chance.

Do you have any ideas of what steps to try? Thanks!

Ah forget what I wrote. Its working now. I guess it was a poor radio module which seems to be the reason in a lot of cases.

@bkl
Hello again!

Is there also support for sending the ack bit from the gw in some way? I saw that this is actually possible in the 2.0 binding. If it's possible how is a "not ack" handled? This would be very useful for e.g. a relay sensor.

I also noticed that you're not the author of the 2.0 binding, I'm sorry for making that assumption.

Thanks!

@bkl

Thank you @bkl! That is the best answer I could have wished for.

I've actually tried some similar prefixes to the port definition, such as "...:38400" and "...@38400" etc. I haven't found any documentation describing the available binding settings more than the port definition that you mention here at the top. I guess the documentation will be more complete for the Openhab 2.0 binding description.

Thank you for your great work here!

Is it possible to change de default baud rate for the 1.8.0 binding? As I'm using a 8 MHz mini for my serial gateway I would like to set the baudrate to 38.4 kbps.

I read that this would be possible for the Openhab 2.0 binding but I'm reluctant to move to Openhab 2.0 as its only a beta at the moment.

Is it possible otherwise to compile a new jar with this lower baud rate? I guess two versions would be enough, 38.4 and 115.2.

Thanks!

After migrating my few sketches to 2.0 and adjusting my baud rate to 38.4 kbps everything works!

Thank you @scalz for pushing me to 2.0 and @ToniA for pointing out the poor choice of baud rate for the 8 Mhz Arduino.

The recommended baud rate is now hard to miss in the 2.0 serial gateway example sketch. So moving to the latest API would possibly have solved my problems anyhow.

// Define a lower baud rate for Arduino's running on 8 MHz (Arduino Pro Mini 3.3V & SenseBender)
#if F_CPU == 8000000L
#define MY_BAUD_RATE 38400
#endif

Moving on to new challenges.

Hi @scalz!

Thank you for answering!

Yhea regarding the serial communication between the nodes of course you are right, I forgot about the nrf24 link. And I know for a fact that the repeater function for the relay node works as I received debug serial information regarding this.

Yes the hardware is mostly 3V3 8 MHz pro minis but I have a couple of Uno clones as well. I'll adjust the baudrate for the serial gateway at least to make sure its more reliable.

Sorry I didn't include that debug information from MYSController but believe me I tried. I tried all sorts of message types and payloads with and without the ack-bit. The gw LED blinked for each transmission but the serial monitoring of the relay sensor was silent. What would be the message to send to the node and can I send it in ASCII or do I need to format it in some way?

I would be wise to move to the new API, especially as I haven't gotten that far yet. But it would be nice to taste some success before moving on to new challenges. I can only handle that many nights of debugging before losing it.

So now I've been through some additional forum threads trying and find something similar. I stumbled upon this one:
https://forum.mysensors.org/topic/3904/node-are-not-receiving-messages-from-domoticz

Luckily I've already tried most of the debugging suggestions on my own initiative.

The comment by @ToniA seems rather important and quite fundamental if you choose an Arduino with a frequnecy other than 16 MHz..

@ToniA said:

8 MHz Arduinos absolutely need to use lower baud rate than 115200. The baud rate is generated from the internal clock, and at 8 MHz 38400 bps is the highest baud rate close enough to the standard.

This isn't obvious to someone who isn't that experienced. The examples assumes the standard 5V 16MHz Arduino but the 3V3 8Mhz is almost as common a choice. This fact is also confirmed if you do some BAUD callculations at: http://wormfood.net/avrbaudcalc.php

I'll try 38.4 kbps for my sensor network and come back with the outcome. This might improve communications in general.

A thought is then how to incorporate my 5V Arduinos in the same network but I guess I can divide the frequency somehow...

Hi!

I'm struggling to get any kind of relay sensor to work. I'm using framework 1.5 for nr24 sensors and serial USB gateway. My other DHT22 sensor is working just fine but the relay sensor must of course also receive messages and I guess somewhere around here lies the problem.

I'm using Openhab as the controller on my RPi2 but while debugging this I've also tried MYSController on my Win7 PC as a way of narrowing this problem down. While troubleshooting on the RPi I also tried to sniff the serial communication so at least I've added that tool (jpnevulator) to my toolbox.

Here's some code I've tried:

/*  RF433Mhz Transmitter node:
    This sketch allows On-Off-Keying (OOK) control of four 433Mhz relay outlets
    which utilize the common PT2262 encoding chip for signal transmission. The sketch could
    be easily expanded to include additional outlets.  The sensor node consists of a nano 
    connected to a NRF24L01 and a 433Mhz transmitter connected to pin 3, 5V and Gnd.  The 
    transmitter can run off of 3.3V as well. 
    
    The sketch is based on the MySensors project (http://www.mysensors.org). 
    Submitted by Dwalt.

    Thanks to https://forum.mysensors.org/user/jribera!
*/ 

//  Include related libraries
#include <MySensor.h>
#include <SPI.h>  
//#include <RF24.h> //wouldn't compile => comment, NickBuilder
#include <RCSwitch.h>

//  Define Constants
#define RF433_CHILD_ID 0
#define NUMBER_OF_OUTLETS 1 // Each outlet will have 2 OOK codes
//#define SEND_DATA 3 //defined in call to function, NickBuilder

#define CODE_1On 1394007
#define CODE_1Off 1394004

MySensor gw;

RCSwitch mySwitch = RCSwitch();

void setup() 
{
    mySwitch.enableTransmit(3); //transmit pin
  
    Serial.begin(115200); // already defined in config, NickBuilder

    //  The node is mains powered, so why not make it a repeater.
   gw.begin(incomingMessage, AUTO, true); //node-id=50, NickBuilder
 
    // Send the sketch version information to gateway
    gw.sendSketchInfo("RF433", "1.1");
 
    // Register outlets to gw (they will be created as child devices)
    for(int i=0; i<NUMBER_OF_OUTLETS;i++) {
        gw.present(i+1, S_LIGHT);
    }

    Serial.println("RF433MHz is awake!");
    
}//setup

void loop() {
    gw.process();
}

void incomingMessage(const MyMessage &message) {
      Serial.print("Outlet #: "); //added these 4 lines for debug, NickBuilder
      Serial.println(message.sensor);
      Serial.print("Command: ");
      Serial.println(message.getBool());
      
  if (message.type==V_LIGHT) {
      int incomingLightState =  message.getBool(); 
      int incomingOutlet = message.sensor;
      
      Serial.print("Outlet #: ");
      Serial.println(message.sensor);
      Serial.print("Command: ");
      Serial.println(message.getBool());
 
      if (incomingOutlet==1) {
          if (incomingLightState==1) {
              // Turn on  socket 1
              Serial.println("Turn on Socket 1");
              mySwitch.send(CODE_1On, 24); // These codes are unique to each outlet
              delay(50); 
          }
          if (incomingLightState==0)  {
              // Turn off socket 1
              Serial.println("Turn off Socket 1");
              mySwitch.send(CODE_1Off, 24);
              delay(50); 
          }
      }//==1      
        
  }//if message.type==V_LIGHT
 
  delay(50);
}//incomingMessage

For some reason I can't initiate the incomingMessage function because if I had then I would have gotten som serial feedback, right?

I've tried sending commands both through the Openhab binding (on runtime 1.8.3) and also though the MYSController but without any sign of feedback in the serial monitor.

Arduino seriel monitor:
send: 50-50-0-0 s=255,c=3,t=15,pt=2,l=2,sg=0,st=ok:0
send: 50-50-0-0 s=255,c=0,t=18,pt=0,l=5,sg=0,st=ok:1.5.4
send: 50-50-0-0 s=255,c=3,t=6,pt=1,l=1,sg=0,st=ok:0
repeater started, id=50, parent=0, distance=1
send: 50-50-0-0 s=255,c=3,t=11,pt=0,l=5,sg=0,st=ok:RF433
send: 50-50-0-0 s=255,c=3,t=12,pt=0,l=3,sg=0,st=ok:1.1
send: 50-50-0-0 s=1,c=0,t=3,pt=0,l=0,sg=0,st=ok:
send: 50-50-0-0 s=2,c=0,t=3,pt=0,l=0,sg=0,st=ok:
send: 50-50-0-0 s=3,c=0,t=3,pt=0,l=0,sg=0,st=ok:
send: 50-50-0-0 s=4,c=0,t=3,pt=0,l=0,sg=0,st=ok:
RF433MHz is awake!

MYSController Debug:
2016-07-14 00:38:18 SIGNING Node 50 does not require signing
2016-07-14 00:38:18 SIGNING MYSController is not signing
2016-07-14 00:38:18 TX 50;255;3;0;15;0
2016-07-14 00:38:18 RX 50;255;3;0;15;0
2016-07-14 00:38:18 DEBUG Update child id=255, type=ARDUINO_RELAY
2016-07-14 00:38:18 RX 50;255;0;0;18;1.5.4
2016-07-14 00:38:18 TX 50;255;3;0;6;M
2016-07-14 00:38:18 RX 50;255;3;0;6;0
2016-07-14 00:38:20 RX 50;255;3;0;11;RF433
2016-07-14 00:38:20 RX 50;255;3;0;12;1.1
2016-07-14 00:38:20 DEBUG Update child id=1, type=LIGHT
2016-07-14 00:38:20 RX 50;1;0;0;3;
2016-07-14 00:38:20 DEBUG Update child id=2, type=LIGHT
2016-07-14 00:38:20 RX 50;2;0;0;3;
2016-07-14 00:38:20 DEBUG Update child id=3, type=LIGHT
2016-07-14 00:38:20 RX 50;3;0;0;3;
2016-07-14 00:38:20 DEBUG Update child id=4, type=LIGHT
2016-07-14 00:38:20 RX 50;4;0;0;3;

If I follow the link in the header to the referenced project @jribera mentions that version 1.4 of the API was used while I'm using 1.5, could this be the cause?

I'm new to MySensors so I might be missing something quite fundamental.

Assistance would be much appreciated, I'm at road's end.

Can someone please assist me regarding this serial connection setup.
I can see in my event log that I receive updates of the Arduino state as below:

Arduino state updated to 99;1;1;0;0;23.7
99;0;1;0;1;37.2

And also in the openhab.log file I get the following types of messages:

[DEBUG] [b.serial.internal.SerialDevice:225  ] - Received message '99;0;1;0;1;37.6
' on serial port /dev/ttyUSB99

But the rule is for some reason not initiated I guess as the println and logInfo i I've added to the top of the rule is absent from the logs. I can see from the tutorial and your posts that you get log information like below but these I cant find in any log.

[INFO ] [runtime.busevents             ]

Possibly I'm missing something in my logback.xml settings or perhaps there is some other reason to this which also might explain why my rule is not started. Perhaps its because I'm using a newer binding for the serial connection? (org.openhab.binding.serial-1.8.3.jar)

Any help would be much appreciated!

Update 1: Perhaps I'll try the mysensors binding and if I'm more successful with that approach I'll skip this serial binding altogether.

Update 2: Ok, I will be using the mysensors binding for the serial connection. I tried it last night and it just worked! And this serial binding approach also demands some quite extensive rule handling of the incoming messages which is not the case with mysensors binding. I think I read somewhere that the mysensors binding will also be available for Openhab 2.0 so hopefully I can continue using it also in the future.

My recommendation for new users of the serial gateway (who also uses openhap as a controller) is to go for the mysensors binding!

I assumed you were using the example mentioned by sundberg84 and in that code it's clear that the interruption is used to increment the pulse count.

If you use a different approach I would very much like to take part of your code. Are you still monitoring your energy and power this way?

Thanks!

Ok, so you see an improvement?

In the referenced thread Korttoma actually mentioned that one could expect a lower range if you set the power to max as the Arduino is not able to supply enough power.

Good to know, learning by doing.

Hi @vga!

This thread presents a lot of hardware considerations related to the nrf24l01 module.

The nrf24 should then perhaps be supplied separately instead of through a Pi or Arduino supply pin. I will go for this approach myself. Even though your USB supply provides 2A the 3V pin is of course limited to perhaps 50 mA?!

Hi!

Would it be possible to use both of the interrupts for two LED sensors or will the interrupts then collide and effect the precision? Of course it would be better if I could use S0-outputs and then perhaps the 12-channel meter described here but in this case I only have the blinking LEDs available.

If multiple interrupts are ok, would it then also be ok to go for even more interrupts, 5 or 6 interrupt pins are available for the Mega if I'm not mistaken. Whats the limit? I guess it depends on the clock frequency and the number of tasks in the loop()?!

Thanks!

I'm also having this problem. Doesn't matter if I downgrade to a previous version of DallasTemperature.

Any progress on this or advice on how to solve this?

The issue seems to be closed, strange...

Thanks!

Thank you @mfalkvidd for the very educational description. I thought that the check could have been as you described but I felt that it was too crude and simple. This doesn't seem to be the most typical use of "exclusive or" but I guess it does the job.

Is it common to only include part of the transmission packet in the parity check? I would have assumed that the nib (Nib4) should be part of the bit check and that the parity bits would then be set or not set so that the complete packet is confirmed.

Anyways I have found description of the protocol with conflicting interpretations so I guess that I anyway will have to do some confirmations regarding the packet content and structure.

Your observation regarding the incomplete first byte led me to find an error in the code I've stolen. I was 4 bits short, thank you!

Hi!

My first post here, please be gentle!

I'm building a MQTT ethernet gateway with 433 MHz receiver and transmitter. I have some cheap wall switches and also a couple of temperature/humidity sensors (UPM/ESIC).

Right now I'm trying to shape the messages which will be relayed from my Arduino.

The protocol for the temperature/humidity sensor is very well explained here:
http://wiki.nethome.nu/doku.php/upmprotocol

But I don't understand the part about the parity bits:
"C = Checksum. bit 1 is XOR of odd bits, bit 0 XOR of even bits in message" (bit 0 and 1 refers to the two LSB of part 4)

Some example data:

Can someone please help me understand the error check algorithm? Also, tips of code which verifies the data parity/integrity are much appreciated!

Regards, Niklas.