Requesting variables from Domoticz

[mfalkvidd]

ok, so on to the next problem.
I am powering using usb through ftdi 3.3V and have a 4.7uF cap on the radio.

This is the serial output:

Begin
send: 10-10-0-0 s=255,c=0,t=17,pt=0,l=3,sg=0,st=ok:1.5
send: 10-10-0-0 s=255,c=3,t=6,pt=1,l=1,sg=0,st=ok:0
sensor started, id=10, parent=0, distance=1
Begone
send: 10-10-0-0 s=255,c=3,t=11,pt=0,l=20,sg=0,st=ok:Plant moisture w bat
send: 10-10-0-0 s=255,c=3,t=12,pt=0,l=3,sg=0,st=ok:1.6
send: 10-10-0-0 s=0,c=0,t=7,pt=0,l=0,sg=0,st=ok:
send: 10-10-0-0 s=1,c=0,t=23,pt=0,l=0,sg=0,st=fail:
read: 0-0-10 s=255,c=3,t=6,pt=0,l=2,sg=0:M

Present sleep time
send: 10-10-0-0 s=2,c=0,t=36,pt=0,l=0,sg=0,st=ok:
Ask for sleep time
send: 10-10-0-0 s=2,c=2,t=47,pt=0,l=0,sg=0,st=fail:
Send default sleep time
send: 10-10-0-0 s=2,c=1,t=47,pt=0,l=18,sg=0,st=fail:DEFAULT_SLEEP_TIME
send: 10-10-0-0 s=0,c=1,t=1,pt=7,l=5,sg=0,st=ok:0.0
send: 10-10-0-0 s=1,c=1,t=38,pt=7,l=5,sg=0,st=ok:3.483
send: 10-10-0-0 s=255,c=3,t=0,pt=1,l=1,sg=0,st=fail:86

This is my code:

#include <SPI.h>
#include <MySensor.h>

#define round(x) ((x)>=0?(long)((x)+0.5):(long)((x)-0.5))
#define N_ELEMENTS(array) (sizeof(array)/sizeof((array)[0]))

#define CHILD_ID_MOISTURE 0
#define CHILD_ID_BATTERY 1
#define CHILD_ID_SLEEP_TIME 2
#define RADIO_DELAY 250
#define BUF_SIZE 25 // max payload for MySensors(NRF24l01)
#define THRESHOLD 1.1 // Only make a new reading with reverse polarity if the change is larger than 10%.
#define DEFAULT_SLEEP_TIME 1800000 // Sleep time between reads (in milliseconds)
#define DEFAULT_CONFIG_TIME 86400000 // Sleep time between config updates (in milliseconds)
#define MIN_SLEEP_TIME 1000 // Do not allow shorter sleep times than 1 second
#define MAX_SLEEP_TIME 86400000 // Do not allow sleep times longer than 24 hours
#define STABILIZATION_TIME 1000 // Let the sensor stabilize before reading
#define BATTERY_FULL 3000 // 3,000 millivolts for 2xAA
#define BATTERY_ZERO 2800 // 1,900 millivolts (1.9V, limit for nrf24l01 without step-up. 2.8V limit for Atmega328 without BOD disabled))
const int SENSOR_ANALOG_PINS[] = {A0, A1}; // Sensor is connected to these two pins. Avoid A3 if using ATSHA204. A6 and A7 cannot be used because they don't have pullups.

MySensor gw;
MyMessage msg(CHILD_ID_MOISTURE, V_HUM);
MyMessage voltage_msg(CHILD_ID_BATTERY, V_VOLTAGE);
MyMessage sleeptimeMsg(CHILD_ID_SLEEP_TIME, V_TEXT);
long oldvoltage = 0;
byte direction = 0;
int oldMoistureLevel = -1;
unsigned long sleeptime_ms = 0;
unsigned long configtime_ms = DEFAULT_CONFIG_TIME;
unsigned long lastConfigCheckTime = 0;
char newMessage[BUF_SIZE];

void setup()
{
  Serial.begin(BAUD_RATE);
  Serial.println("Begin");
  gw.begin(incomingMessage);
  Serial.println("Begone");

  gw.sendSketchInfo("Plant moisture w bat", "1.6");

  gw.present(CHILD_ID_MOISTURE, S_HUM);
  gw.wait(RADIO_DELAY);
  gw.present(CHILD_ID_BATTERY, S_CUSTOM);
  for (int i = 0; i < N_ELEMENTS(SENSOR_ANALOG_PINS); i++) {
    pinMode(SENSOR_ANALOG_PINS[i], OUTPUT);
    digitalWrite(SENSOR_ANALOG_PINS[i], LOW);
  }
  gw.wait(RADIO_DELAY);
  Serial.println("Present sleep time");
  gw.present(CHILD_ID_SLEEP_TIME, S_INFO);
  gw.wait(RADIO_DELAY);
  fetchConfig();
}
void fetchConfig() {
  // Request latest sleep time
  Serial.println("Ask for sleep time");
  gw.request(CHILD_ID_SLEEP_TIME, V_TEXT);
  gw.wait(RADIO_DELAY); // Hopefully we'll get an incoming message during this wait
  // If we didn't get any sleeptime, sleeptime will be 0.
  // Ask the controller to create the variable by sending the default value
  if (sleeptime_ms == 0) {
    sleeptime_ms = DEFAULT_SLEEP_TIME;
    Serial.println("Send default sleep time");
    gw.send(sleeptimeMsg.set("DEFAULT_SLEEP_TIME")); // TODO: Send value as string instead
  }
  lastConfigCheckTime = millis();
}

To troubleshoot this, I cross-reference the source and the serial API, right? (I really wish there was an easier way than to cross-reference the position in the debug output with the three-line command in the source and then cross-reference that with the the serial api.)
So

send: 10-10-0-0 s=1,c=0,t=23,pt=0,l=0,sg=0,st=fail:

means the following:

• 10: the sender was node 10
• 10: the message comes directly from node 10
• 0: the message is sent to node 0 (the gateway)
• 0: the message final destination is 0
• s=1: the message is from sensor 1
• c=0: the command is 0 - are commands documented somewhere? I've seen c=0, c=1, c=2 and c=3)
• t=23: the message type is 23 - which isn't a valid message type according to the serial API documentation
• pt=0: the payload type is 0, which means S_DOOR - I don't use S_DOOR anywhere in my sketch so where did this come from?
• l=0: the length of the payload is 0
• sg=0: the payload is not signed
• st=fail: the message failed
• : the payload is empty

Can anyone explain the values for c, t, and pt?

[BartE]

@mfalkvidd well it is explained here

c=message type
0 = presentation Sent by a node when they present attached sensors. This is usually done in setup() at startup.
1 = (set) This message is sent from or to a sensor when a sensor value should be updated
2 = (req) Requests a variable value (usually from an actuator destined for controller).
3 = (interal) This is a special internal message. (like batery level, time, version, config etc...)
4 = Used for OTA firmware updates

t=sub type
0 should send the V_TEMP
23 should send the V_LIGHT_LEVEL

pt=payload type
0 = STRING
1 = BYTE
2 = INT16
3 = UINT16
4 = LONG32
5 = ULONG32,
6= CUSTOM,
7 = FLOAT32

[mfalkvidd]

@BartE I know parts of it is explained in the serial API. That's why I linked to the serial API :-)
However, that page does not explain that c= in the debug output is message type.
But it seems I got a off by one error when trying to cross-reference the debug output with the source code I linked to. The person who write this comment seems to be as confused as I am.

Anyway, thanks for taking time to explain. I'll do some more troubleshooting and report back.

[martinhjelmare]

@mfalkvidd

This confusion is why I asked you to add the information from my post below, to the troubleshooting sticky post:
http://forum.mysensors.org/topic/2579/about-serial-api-1-5/2

[mfalkvidd]

@martinhjelmare said:

This confusion is why I asked you to add the information from my post below, to the troubleshooting sticky post:
http://forum.mysensors.org/topic/2579/about-serial-api-1-5/2

Thanks! I knew I has seen an explanation that made sense somewhere :-) Must have lost that task. I have updated the troubleshooting post now.

[martinhjelmare]

@mfalkvidd

Great, thanks. It would be even better if it got merged into the top post, but at least it's in a topic where people can find it more easy now.

[mfalkvidd]

The first post is already quite heavy, I don't want to add to the big wall of text. But maybe having a separate post isn't better.

I'll see if I can merge it in a nice way. I'll also change the links to the source code to point to a specific commit. The line number references will not make any sense in the future if the links point to HEAD.

[martinhjelmare]

@mfalkvidd

I think adding headers to different sections in the post, will make it easier to read:

Header 1

Header 1
========

Header 2

Header 2
--------

http://kramdown.gettalong.org/syntax.html#headers
Don't know if all this markdown is supported.

Good to update the links to be futureproof. :thumbsup:

[mfalkvidd]

futureproof links fixed - @martinhjelmare could you please check that I found the right lines (your links were already obsolete :) )
Have added a header as well, great suggestion. Will look at merging with the first post later, I think it will require some re-formatting of the first post to look good.

[martinhjelmare]

@mfalkvidd

Looks good!

When you merge this info, to make it complete, I think you should add what the three digits after "read" or "send" mean:
"0;0;3;0;9;read: 3-3-0 s=0,c=1,t=24,pt=0,l=11,sg=0:27"

Those are the node ids of sender_node - last_node - destination_node from left to right. So in the example it's node 3 that sent the message, and node 3 was also the last node before the gateway received the message, and it's the gateway (node 0) that is the destination.

Edit:

For sending there are four digits: 0-0-3-3
sender - last - to - destination
where to is similar to last, ie the node after the first hop in the network, if I understand correctly.

[MikeF]

@mfalkvidd said:

• t=23: the message type is 23 - which isn't a valid message type according to the serial API documentation

Following your comment earlier in this thread, I copied V_TEXT and S_INFO from the development branch into MyMessage.h. V_TEXT occupies position 47 in the typedef enum for '//Type of sensor data' in my version of MyMessage.h - when you copied it, did it go into position 23?

[mfalkvidd]

@MikeF I don't have access to the code now, but you are probably right. I need to copy the whole enum, selectively copying doesn't work.