💬 NodeManager
-
@user2684, Will you like to consider adding a #DEFINE to let user configure PowerOn function to select "GND-On" or "Vcc-On" (5V0)?
With this GND-On PowerOn, a single GND wire controlled by a digital pin can control the power instead of 2 wire poweron control. [so many control words :)]
For devices that require more than ~10mA current (~Arduino pin current) this GND-On configuration can help externally supplied higher powered V+ current to switch the devices! Thus, will also help 3V3 devices to be controlled by PowerOn, of course, with external 3V3!
-
I just started using NodeManager, mainly for the ability to send settings to the node.
I started with a plain analog (Voltage) sensor, and it works just fine. But I cannot make a DS18B20 sensor to send any temperature data. It registers on the gateway, and that's it.
I have enabled the DS18B20 module in the config.h.
This is the code in the sketch:/* * Register below your sensors */ nodeManager.setSleepSeconds(10); nodeManager.setReportIntervalSeconds(10); int temp = nodeManager.registerSensor(SENSOR_DS18B20); /* * Register above your sensors */Am I missing something?
-
@kted I think you forgot the pin to which the sensor is attached to. e.g.
nodeManager.registerSensor(SENSOR_DS18B20,6); -
@user2684 Actually, you are right. Thank you.
But shouldn't the compiler throw an error?Now to the hard part: How to send the actual command from Domoticz, for example to change the sleep duration...
@kted Such functionality it's supposed to be hard-coded in the node sketch. But if you want to make it modificable from Domoticz, perhaps you can make use of the V_VAR1-3 variables and modify them in domoticz, receive them in the node and pass to NodeManager.
-
@user2684 Actually, you are right. Thank you.
But shouldn't the compiler throw an error?Now to the hard part: How to send the actual command from Domoticz, for example to change the sleep duration...
@kted the compiler doesn't complain because for some sensors (e.g. those using i2c), the pin is not required so I made it not mandatory. As for Domoticz, I'll let others to address your question since I don't know that controller enough. Thanks
-
@user2684 I have looked at the changes in https://github.com/mysensors/NodeManager/pull/174 which incorporates an alternative improved implementation for the _LoadConfig/_SaveConfig functions (interesting that using an intermediate union requires less code than my shifting version- presumably due to differences in the way the GCC optimiser works for an AVR target).
I spotted a coupld of minor points and was also able to further reduce the code size.
Firstly as we are writing C++ rather than C the declaration of the union should just be
// Local union used to split _sleep_time into bytes
union tLongByteArrayCombo{
long long_value;
uint8_t byte_array[4];
} ;
(The typedef systax, although valid C++ is unnecessary - a simple union declaration is sufficient.)
There is also a typo - the original had a member called byte_arrray instead of byte_array.You can also save 24 bytes of code by avoiding the use of a local union variable and simply aliasing _sleep_time as the union type. So instead of _load_config doing -
tLongByteArrayCombo c;
c.byte_array[0] = loadState(EEPROM_SLEEP_1);
c.byte_array[1] = loadState(EEPROM_SLEEP_2);
c.byte_array[2] = loadState(EEPROM_SLEEP_3);
c.byte_array[3] = 0;
_sleep_time = c.long_value;
You can do
(((tLongByteArrayCombo&)_sleep_time).byte_array )[0] = loadState(EEPROM_SLEEP_1);
(((tLongByteArrayCombo&)_sleep_time).byte_array )[1] = loadState(EEPROM_SLEEP_2);
(((tLongByteArrayCombo&)_sleep_time).byte_array )[2] = loadState(EEPROM_SLEEP_3);
(((tLongByteArrayCombo&)_sleep_time).byte_array )[3] = 0;
And in _save_config instead of
tLongByteArrayCombo c;
c.long_value = _sleep_time;
saveState(EEPROM_SLEEP_1, c.byte_array[0]);
saveState(EEPROM_SLEEP_2, c.byte_array[1]);
saveState(EEPROM_SLEEP_3, c.byte_array[2]);
you can use
saveState(EEPROM_SLEEP_1, (((tLongByteArrayCombo&)_sleep_time).byte_array )[0] );
saveState(EEPROM_SLEEP_2, (((tLongByteArrayCombo&)_sleep_time).byte_array )[1] );
saveState(EEPROM_SLEEP_3, (((tLongByteArrayCombo&)_sleep_time).byte_array )[2] );In my specific sample sketch I had the following code sizes
Original NodeManager.cpp 28242 Bytes
NodeManager with patch from pull rq 174 - 28154 Bytes (saving of 88 Bytes of code(
Patched NodeManager with additional changes above - 28130 Bytes ( saving another 24 Bytes of code) -
@user2684 I have looked at the changes in https://github.com/mysensors/NodeManager/pull/174 which incorporates an alternative improved implementation for the _LoadConfig/_SaveConfig functions (interesting that using an intermediate union requires less code than my shifting version- presumably due to differences in the way the GCC optimiser works for an AVR target).
I spotted a coupld of minor points and was also able to further reduce the code size.
Firstly as we are writing C++ rather than C the declaration of the union should just be
// Local union used to split _sleep_time into bytes
union tLongByteArrayCombo{
long long_value;
uint8_t byte_array[4];
} ;
(The typedef systax, although valid C++ is unnecessary - a simple union declaration is sufficient.)
There is also a typo - the original had a member called byte_arrray instead of byte_array.You can also save 24 bytes of code by avoiding the use of a local union variable and simply aliasing _sleep_time as the union type. So instead of _load_config doing -
tLongByteArrayCombo c;
c.byte_array[0] = loadState(EEPROM_SLEEP_1);
c.byte_array[1] = loadState(EEPROM_SLEEP_2);
c.byte_array[2] = loadState(EEPROM_SLEEP_3);
c.byte_array[3] = 0;
_sleep_time = c.long_value;
You can do
(((tLongByteArrayCombo&)_sleep_time).byte_array )[0] = loadState(EEPROM_SLEEP_1);
(((tLongByteArrayCombo&)_sleep_time).byte_array )[1] = loadState(EEPROM_SLEEP_2);
(((tLongByteArrayCombo&)_sleep_time).byte_array )[2] = loadState(EEPROM_SLEEP_3);
(((tLongByteArrayCombo&)_sleep_time).byte_array )[3] = 0;
And in _save_config instead of
tLongByteArrayCombo c;
c.long_value = _sleep_time;
saveState(EEPROM_SLEEP_1, c.byte_array[0]);
saveState(EEPROM_SLEEP_2, c.byte_array[1]);
saveState(EEPROM_SLEEP_3, c.byte_array[2]);
you can use
saveState(EEPROM_SLEEP_1, (((tLongByteArrayCombo&)_sleep_time).byte_array )[0] );
saveState(EEPROM_SLEEP_2, (((tLongByteArrayCombo&)_sleep_time).byte_array )[1] );
saveState(EEPROM_SLEEP_3, (((tLongByteArrayCombo&)_sleep_time).byte_array )[2] );In my specific sample sketch I had the following code sizes
Original NodeManager.cpp 28242 Bytes
NodeManager with patch from pull rq 174 - 28154 Bytes (saving of 88 Bytes of code(
Patched NodeManager with additional changes above - 28130 Bytes ( saving another 24 Bytes of code)@graham86 I guess you are referring to https://github.com/mysensors/NodeManager/pull/217, not 174, am I wrong? Anyway, any contribution that would help saving bytes is more than welcome: NodeManager is becoming more and more complex and the situations where we are out of storage start increasing so we definitely need to save whatever wherever we can :-) Regarding what you are proposing above, keep on eye on PR #217; once a new one dedicated to this part of the code will be created as discussed there, feel free to add your own PR to that branch or just let me know and I'll do it for you. Thanks!
-
@vikasjee sorry my bad, I think I couldn't understand your suggestion :) Do you have an example to let me understand better? thanks and sorry again, I'm sure I'm missing something somewhere :)
@user2684, Sorry, couldn't revert to your query earlier as i was away building a small library.
Expanding onto my earlier post on the requested Power Management feature -
A simple switch will complete a circuit whenever its switched ON. This allows for placing the switch on the ground return wire too. So only a single GND-ON (Switched ON) will complete the circuit (without requiring an additional Vcc-ON switch).Now, with a developer configured #DEFINE GND_ON_POWER =1 may be checked in NodeManager's PowerManagement functions to DigitalWrite(Digital_GND_ON_Pin, LOW)
for a switchON effect.Additionally, To provide an extra current to a sensor (i.e. more than a ~10mA-20mA, a max safe current provided by an Arduino pin) an external power source (other than Arduino +5V0 OR +3V3) may be provided by that external power source (of course with with a common ground wire between Arduino and that powersource to complete the circuit.)
Also, with the current 2Wire PowerOn methodology, the VccPowerOn switch can provide only one positive voltage (that provided by Arduino Vcc, say +5V0) but not +3V3 (say) to the sensors. If some attached sensors require the other voltage (+3V3), then, this 2Wire PowerOn method will not help. Whereas, a single GND_On power methodology will still switch the circuit thus managing the Power to those sensors too.
[PS: Signal Voltage Levels will still need to be managed by the developer attaching those sensors to the node]I think this simple feature will add on to the power of the PowerManagement functions.
Hope this clears some air ? Open to suggestions...
-
@user2684, Sorry, couldn't revert to your query earlier as i was away building a small library.
Expanding onto my earlier post on the requested Power Management feature -
A simple switch will complete a circuit whenever its switched ON. This allows for placing the switch on the ground return wire too. So only a single GND-ON (Switched ON) will complete the circuit (without requiring an additional Vcc-ON switch).Now, with a developer configured #DEFINE GND_ON_POWER =1 may be checked in NodeManager's PowerManagement functions to DigitalWrite(Digital_GND_ON_Pin, LOW)
for a switchON effect.Additionally, To provide an extra current to a sensor (i.e. more than a ~10mA-20mA, a max safe current provided by an Arduino pin) an external power source (other than Arduino +5V0 OR +3V3) may be provided by that external power source (of course with with a common ground wire between Arduino and that powersource to complete the circuit.)
Also, with the current 2Wire PowerOn methodology, the VccPowerOn switch can provide only one positive voltage (that provided by Arduino Vcc, say +5V0) but not +3V3 (say) to the sensors. If some attached sensors require the other voltage (+3V3), then, this 2Wire PowerOn method will not help. Whereas, a single GND_On power methodology will still switch the circuit thus managing the Power to those sensors too.
[PS: Signal Voltage Levels will still need to be managed by the developer attaching those sensors to the node]I think this simple feature will add on to the power of the PowerManagement functions.
Hope this clears some air ? Open to suggestions...
@vikasjee thanks all clear now! I'll track this with https://github.com/mysensors/NodeManager/issues/224. Thanks again for the detailed explanation!
-
Hello all, just to let you know when compiling against the latest version of the mysensors 2.2.0-beta library, NodeManager will crash on startup, just after presenting the mysensors logo. Thanks @gohan for pointing this out! Root cause is still unknown but when MY_DEBUG is defined, the crash doesn't take place (https://github.com/mysensors/NodeManager/issues/223)
-
Hello all, just to let you know when compiling against the latest version of the mysensors 2.2.0-beta library, NodeManager will crash on startup, just after presenting the mysensors logo. Thanks @gohan for pointing this out! Root cause is still unknown but when MY_DEBUG is defined, the crash doesn't take place (https://github.com/mysensors/NodeManager/issues/223)
-
I'm afraid that issue 223 is not a NodeManager failure. I can reproduce it in a new sketch without using NodeManager.
Other issue with MySensors are, NRF24 doesn't link with controller.
If MY_DEBUG_VERBOSE_RF24 is defined, it automagically works. -
I'm afraid that issue 223 is not a NodeManager failure. I can reproduce it in a new sketch without using NodeManager.
Other issue with MySensors are, NRF24 doesn't link with controller.
If MY_DEBUG_VERBOSE_RF24 is defined, it automagically works. -
@Sergio-Rius, with RF24_VERBOSE on, the system crashes in 40-50 seconds especially if you're connected to the serial monitor or if your serial gateway has this #DEFINE on.
Still more strange, suddenly started to work properly on 2/3 of my testing nodes. That killed me.
What about the gateways you are using? And the controllers?
-
Hi,
I'm having trouble with the motion sample code. I have changed the setSleepHours(1) command to setSleepMinutes(1). I understand that the sensor will send a hart beat every 1 min. This is working fine for the hart beat, but evertime the hart beat is send the sensor sends a Trigger messages as well even though the sensor is not triggered. I thought that maybe there is a power dip and that it might cause the PIR (RS501) to send a interrupt, but I have removed the setSleepMinutes command and replaced it with a setBatteryReportHours(1) command. This command is send correctly and the sensor only sends the trigger command when the PIR is triggered. Did anyone have a similar issue?
Attached is the sensor debug output when the setSleepMinutes command is used:
0 MCO:BGN:INIT NODE,CP=RNNNA--,VER=2.1.1 40 MCO:BGN:BFR REG I=1 P=3 P=1 T=16 NodeManager v1.6 LIB V=2.1.1 R=N T=N A=A S=- B=- INT P=3 M=1 INT P=2 M=255 96 TSM:INIT 176 TSF:WUR:MS=0 198 TSM:INIT:TSP OK 219 TSM:INIT:STATID=3 243 TSF:SID:OK,ID=3 264 TSM:FPAR 313 TSF:MSG:SEND,3-3-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 385 TSF:MSG:READ,0-0-3,s=255,c=3,t=8,pt=1,l=1,sg=0:0 440 TSF:MSG:FPAR OK,ID=0,D=1 2387 TSM:FPAR:OK 2404 TSM:ID 2418 TSM:ID:OK 2433 TSM:UPL 2449 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1 2521 TSF:MSG:READ,0-0-3,s=255,c=3,t=25,pt=1,l=1,sg=0:1 2578 TSF:MSG:PONG RECV,HP=1 2607 TSM:UPL:OK 2625 TSM:READY:ID=3,PAR=0,DIS=1 2660 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=OK:0100 2734 TSF:MSG:READ,0-0-3,s=255,c=3,t=15,pt=6,l=2,sg=0:0100 2797 TSF:MSG:SEND,3-3-0-0,s=255,c=0,t=17,pt=0,l=5,sg=0,ft=0,st=OK:2.1.1 2875 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=6,pt=1,l=1,sg=0,ft=0,st=OK:0 2945 TSF:MSG:READ,0-0-3,s=255,c=3,t=6,pt=0,l=1,sg=0:M RADIO OK 3004 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=11,pt=0,l=11,sg=0,ft=0,st=OK:NodeManager 3096 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=12,pt=0,l=3,sg=0,ft=0,st=OK:1.0 PRES I=200, T=23 3170 TSF:MSG:SEND,3-3-0-0,s=200,c=0,t=23,pt=0,l=0,sg=0,ft=0,st=OK: PRES I=201, T=30 3260 TSF:MSG:SEND,3-3-0-0,s=201,c=0,t=30,pt=0,l=0,sg=0,ft=0,st=OK: BATT V=3.30 P=100 SEND D=0 I=201 C=0 T=38 S= I=0 F=3.30 3418 !MCO:SND:NODE NOT REG 3506 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=0,pt=1,l=1,sg=0,ft=0,st=OK:100 PRES I=1 T=1 3579 TSF:MSG:SEND,3-3-0-0,s=1,c=0,t=1,pt=0,l=0,sg=0,ft=0,st=OK: READY 3659 MCO:REG:REQ 3688 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=26,pt=1,l=1,sg=0,ft=0,st=OK:2 3760 TSF:MSG:READ,0-0-3,s=255,c=3,t=27,pt=1,l=1,sg=0:1 3817 MCO:PIM:NODE REG=1 3842 MCO:BGN:STP MY I=3 M=1 3860 MCO:BGN:INIT OK,TSP=1 SLEEP 60s 3901 MCO:SLP:MS=60000,SMS=1,I1=1,M1=1,I2=255,M2=255 3971 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=22,pt=5,l=4,sg=0,ft=0,st=OK:127 4544 MCO:SLP:TPD 4560 MCO:SLP:WUP=1 INT P=3, M=1 AWAKE SWITCH I=1 P=3 V=1 SEND D=0 I=1 C=0 T=16 S= I=1 F=0.00 4597 TSF:MSG:SEND,3-3-0-0,s=1,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=OK:1 SLEEP 60s 4732 MCO:SLP:MS=60000,SMS=1,I1=1,M1=1,I2=255,M2=255 4800 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=22,pt=5,l=4,sg=0,ft=0,st=OK:956 5376 MCO:SLP:TPD 5392 MCO:SLP:WUP=1 INT P=3, M=1 AWAKE SWITCH I=1 P=3 V=0 SEND D=0 I=1 C=1 T=16 S= I=0 F=0.00 5429 TSF:MSG:SEND,3-3-0-0,s=1,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=OK:0 SLEEP 60s 5564 MCO:SLP:MS=60000,SMS=1,I1=1,M1=1,I2=255,M2=255 5632 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=22,pt=5,l=4,sg=0,ft=0,st=OK:1787 6207 MCO:SLP:TPD 6223 MCO:SLP:WUP=-1 AWAKE SLEEP 60s 6246 MCO:SLP:MS=60000,SMS=1,I1=1,M1=1,I2=255,M2=255 6322 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=22,pt=5,l=4,sg=0,ft=0,st=OK:2478 6897 MCO:SLP:TPD 6914 MCO:SLP:WUP=1 INT P=3, M=1 AWAKE SWITCH I=1 P=3 V=1 SEND D=0 I=1 C=1 T=16 S= I=1 F=0.00 6950 TSF:MSG:SEND,3-3-0-0,s=1,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=OK:1 SLEEP 60s 7086 MCO:SLP:MS=60000,SMS=1,I1=1,M1=1,I2=255,M2=255 7153 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=22,pt=5,l=4,sg=0,ft=0,st=OK:3309 7729 MCO:SLP:TPD 7745 MCO:SLP:WUP=1 INT P=3, M=1 AWAKE SWITCH I=1 P=3 V=0 SEND D=0 I=1 C=1 T=16 S= I=0 F=0.00 7782 TSF:MSG:SEND,3-3-0-0,s=1,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=OK:0 SLEEP 60s 7917 MCO:SLP:MS=60000,SMS=1,I1=1,M1=1,I2=255,M2=255 7985 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=22,pt=5,l=4,sg=0,ft=0,st=OK:4141 8560 MCO:SLP:TPD 8577 MCO:SLP:WUP=-1 AWAKE SLEEP 60s 8599 MCO:SLP:MS=60000,SMS=1,I1=1,M1=1,I2=255,M2=255 8675 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=22,pt=5,l=4,sg=0,ft=0,st=OK:4831 9252 MCO:SLP:TPD 9269 MCO:SLP:WUP=1 INT P=3, M=1 AWAKE SWITCH I=1 P=3 V=1 SEND D=0 I=1 C=1 T=16 S= I=1 F=0.00 9306 TSF:MSG:SEND,3-3-0-0,s=1,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=OK:1 SLEEP 60s 9441 MCO:SLP:MS=60000,SMS=1,I1=1,M1=1,I2=255,M2=255 9508 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=22,pt=5,l=4,sg=0,ft=0,st=OK:5664 10084 MCO:SLP:TPD 10102 MCO:SLP:WUP=1 INT P=3, M=1 AWAKE SWITCH I=1 P=3 V=0 SEND D=0 I=1 C=1 T=16 S= I=0 F=0.00 10139 TSF:MSG:SEND,3-3-0-0,s=1,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=OK:0 SLEEP 60s 10274 MCO:SLP:MS=60000,SMS=1,I1=1,M1=1,I2=255,M2=255 10344 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=22,pt=5,l=4,sg=0,ft=0,st=OK:6500 10921 MCO:SLP:TPD -
Hi,
I'm having trouble with the motion sample code. I have changed the setSleepHours(1) command to setSleepMinutes(1). I understand that the sensor will send a hart beat every 1 min. This is working fine for the hart beat, but evertime the hart beat is send the sensor sends a Trigger messages as well even though the sensor is not triggered. I thought that maybe there is a power dip and that it might cause the PIR (RS501) to send a interrupt, but I have removed the setSleepMinutes command and replaced it with a setBatteryReportHours(1) command. This command is send correctly and the sensor only sends the trigger command when the PIR is triggered. Did anyone have a similar issue?
Attached is the sensor debug output when the setSleepMinutes command is used:
0 MCO:BGN:INIT NODE,CP=RNNNA--,VER=2.1.1 40 MCO:BGN:BFR REG I=1 P=3 P=1 T=16 NodeManager v1.6 LIB V=2.1.1 R=N T=N A=A S=- B=- INT P=3 M=1 INT P=2 M=255 96 TSM:INIT 176 TSF:WUR:MS=0 198 TSM:INIT:TSP OK 219 TSM:INIT:STATID=3 243 TSF:SID:OK,ID=3 264 TSM:FPAR 313 TSF:MSG:SEND,3-3-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 385 TSF:MSG:READ,0-0-3,s=255,c=3,t=8,pt=1,l=1,sg=0:0 440 TSF:MSG:FPAR OK,ID=0,D=1 2387 TSM:FPAR:OK 2404 TSM:ID 2418 TSM:ID:OK 2433 TSM:UPL 2449 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1 2521 TSF:MSG:READ,0-0-3,s=255,c=3,t=25,pt=1,l=1,sg=0:1 2578 TSF:MSG:PONG RECV,HP=1 2607 TSM:UPL:OK 2625 TSM:READY:ID=3,PAR=0,DIS=1 2660 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=OK:0100 2734 TSF:MSG:READ,0-0-3,s=255,c=3,t=15,pt=6,l=2,sg=0:0100 2797 TSF:MSG:SEND,3-3-0-0,s=255,c=0,t=17,pt=0,l=5,sg=0,ft=0,st=OK:2.1.1 2875 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=6,pt=1,l=1,sg=0,ft=0,st=OK:0 2945 TSF:MSG:READ,0-0-3,s=255,c=3,t=6,pt=0,l=1,sg=0:M RADIO OK 3004 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=11,pt=0,l=11,sg=0,ft=0,st=OK:NodeManager 3096 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=12,pt=0,l=3,sg=0,ft=0,st=OK:1.0 PRES I=200, T=23 3170 TSF:MSG:SEND,3-3-0-0,s=200,c=0,t=23,pt=0,l=0,sg=0,ft=0,st=OK: PRES I=201, T=30 3260 TSF:MSG:SEND,3-3-0-0,s=201,c=0,t=30,pt=0,l=0,sg=0,ft=0,st=OK: BATT V=3.30 P=100 SEND D=0 I=201 C=0 T=38 S= I=0 F=3.30 3418 !MCO:SND:NODE NOT REG 3506 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=0,pt=1,l=1,sg=0,ft=0,st=OK:100 PRES I=1 T=1 3579 TSF:MSG:SEND,3-3-0-0,s=1,c=0,t=1,pt=0,l=0,sg=0,ft=0,st=OK: READY 3659 MCO:REG:REQ 3688 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=26,pt=1,l=1,sg=0,ft=0,st=OK:2 3760 TSF:MSG:READ,0-0-3,s=255,c=3,t=27,pt=1,l=1,sg=0:1 3817 MCO:PIM:NODE REG=1 3842 MCO:BGN:STP MY I=3 M=1 3860 MCO:BGN:INIT OK,TSP=1 SLEEP 60s 3901 MCO:SLP:MS=60000,SMS=1,I1=1,M1=1,I2=255,M2=255 3971 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=22,pt=5,l=4,sg=0,ft=0,st=OK:127 4544 MCO:SLP:TPD 4560 MCO:SLP:WUP=1 INT P=3, M=1 AWAKE SWITCH I=1 P=3 V=1 SEND D=0 I=1 C=0 T=16 S= I=1 F=0.00 4597 TSF:MSG:SEND,3-3-0-0,s=1,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=OK:1 SLEEP 60s 4732 MCO:SLP:MS=60000,SMS=1,I1=1,M1=1,I2=255,M2=255 4800 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=22,pt=5,l=4,sg=0,ft=0,st=OK:956 5376 MCO:SLP:TPD 5392 MCO:SLP:WUP=1 INT P=3, M=1 AWAKE SWITCH I=1 P=3 V=0 SEND D=0 I=1 C=1 T=16 S= I=0 F=0.00 5429 TSF:MSG:SEND,3-3-0-0,s=1,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=OK:0 SLEEP 60s 5564 MCO:SLP:MS=60000,SMS=1,I1=1,M1=1,I2=255,M2=255 5632 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=22,pt=5,l=4,sg=0,ft=0,st=OK:1787 6207 MCO:SLP:TPD 6223 MCO:SLP:WUP=-1 AWAKE SLEEP 60s 6246 MCO:SLP:MS=60000,SMS=1,I1=1,M1=1,I2=255,M2=255 6322 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=22,pt=5,l=4,sg=0,ft=0,st=OK:2478 6897 MCO:SLP:TPD 6914 MCO:SLP:WUP=1 INT P=3, M=1 AWAKE SWITCH I=1 P=3 V=1 SEND D=0 I=1 C=1 T=16 S= I=1 F=0.00 6950 TSF:MSG:SEND,3-3-0-0,s=1,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=OK:1 SLEEP 60s 7086 MCO:SLP:MS=60000,SMS=1,I1=1,M1=1,I2=255,M2=255 7153 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=22,pt=5,l=4,sg=0,ft=0,st=OK:3309 7729 MCO:SLP:TPD 7745 MCO:SLP:WUP=1 INT P=3, M=1 AWAKE SWITCH I=1 P=3 V=0 SEND D=0 I=1 C=1 T=16 S= I=0 F=0.00 7782 TSF:MSG:SEND,3-3-0-0,s=1,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=OK:0 SLEEP 60s 7917 MCO:SLP:MS=60000,SMS=1,I1=1,M1=1,I2=255,M2=255 7985 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=22,pt=5,l=4,sg=0,ft=0,st=OK:4141 8560 MCO:SLP:TPD 8577 MCO:SLP:WUP=-1 AWAKE SLEEP 60s 8599 MCO:SLP:MS=60000,SMS=1,I1=1,M1=1,I2=255,M2=255 8675 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=22,pt=5,l=4,sg=0,ft=0,st=OK:4831 9252 MCO:SLP:TPD 9269 MCO:SLP:WUP=1 INT P=3, M=1 AWAKE SWITCH I=1 P=3 V=1 SEND D=0 I=1 C=1 T=16 S= I=1 F=0.00 9306 TSF:MSG:SEND,3-3-0-0,s=1,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=OK:1 SLEEP 60s 9441 MCO:SLP:MS=60000,SMS=1,I1=1,M1=1,I2=255,M2=255 9508 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=22,pt=5,l=4,sg=0,ft=0,st=OK:5664 10084 MCO:SLP:TPD 10102 MCO:SLP:WUP=1 INT P=3, M=1 AWAKE SWITCH I=1 P=3 V=0 SEND D=0 I=1 C=1 T=16 S= I=0 F=0.00 10139 TSF:MSG:SEND,3-3-0-0,s=1,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=OK:0 SLEEP 60s 10274 MCO:SLP:MS=60000,SMS=1,I1=1,M1=1,I2=255,M2=255 10344 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=22,pt=5,l=4,sg=0,ft=0,st=OK:6500 10921 MCO:SLP:TPD@FredRoot this is weird, from the logs looks like there is kind of a floating interrupt (alternatively 1 and 0). The strange thing is that the interrupt is coming from the call to mysensors' sleep() function which is returning a positive number corresponding to the interrupt linked to pin 3 instead of a negative value like it should after a sleeping cycle. Anybody else experiencing this behavior with NodeManager v1.6? thanks
-
@user2684 can you add support for the Si7021 sensor as found in sensebender micro?
https://www.mysensors.org/hardware/microalso, 2nd question.
how do i register a sensor that is onboard?
you ask for a child id and pin that it's on. but if it's an onboard sensor. how do you make that work? just omit the pin? -
@user2684 can you add support for the Si7021 sensor as found in sensebender micro?
https://www.mysensors.org/hardware/microalso, 2nd question.
how do i register a sensor that is onboard?
you ask for a child id and pin that it's on. but if it's an onboard sensor. how do you make that work? just omit the pin?@mvader for question #1, I've added it to the existing issue https://github.com/mysensors/NodeManager/issues/221. For question #2, for sensors using i2c the pin is not required despite within the code nodemanager will set a random pin (have a look at SensorSHT21 for example)
-
@mvader for question #1, I've added it to the existing issue https://github.com/mysensors/NodeManager/issues/221. For question #2, for sensors using i2c the pin is not required despite within the code nodemanager will set a random pin (have a look at SensorSHT21 for example)
@user2684 said in 💬 NodeManager:
@mvader for question #1, I've added it to the existing issue https://github.com/mysensors/NodeManager/issues/221. For question #2, for sensors using i2c the pin is not required despite within the code nodemanager will set a random pin (have a look at SensorSHT21 for example)
great.. thank you!
