Requesting variables from Domoticz
-
@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 updatest=sub type
0 should send the V_TEMP
23 should send the V_LIGHT_LEVELpt=payload type
0 = STRING
1 = BYTE
2 = INT16
3 = UINT16
4 = LONG32
5 = ULONG32,
6= CUSTOM,
7 = FLOAT32 -
@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 updatest=sub type
0 should send the V_TEMP
23 should send the V_LIGHT_LEVELpt=payload type
0 = STRING
1 = BYTE
2 = INT16
3 = UINT16
4 = LONG32
5 = ULONG32,
6= CUSTOM,
7 = FLOAT32@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.
-
@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.
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 -
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@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/2Thanks! I knew I has seen an explanation that made sense somewhere :-) Must have lost that task. I have updated the troubleshooting post now.
-
@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/2Thanks! I knew I has seen an explanation that made sense somewhere :-) Must have lost that task. I have updated the troubleshooting post now.
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.
-
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.
-
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.
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:
-
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. -
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.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. -
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:86This 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.)
Sosend: 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?
@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 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?
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login