Posts made by cimba007

Its not "that" bad .. the Attiny44A is compatible with Arduino thanks to https://github.com/SpenceKonde/ATTinyCore

For now I got Humidity and Voltage(VCC) running up fine.

From time to time I run into this bug .. not sure if this is related:

0;255;3;0;9;TSM:READY:NWD REQ<\n>
0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:<\n>
Fatal exception 28(LoadProhibitedCause):<\n>
epc1=0x40202704, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00000003, depc=0x00000000<\n>
<\r><\n>

I might have run into a bug in the calculation of message length.

In my handcrafted packet I use this as the 4thy byte send:

0b10000001

So to craft this I looked at MyMessage.h which showed me this:

uint8_t version_length;		 // 2 bit - Protocol version
		                 // 1 bit - Signed flag
		                 // 5 bit - Length of payload

So from my understanding:

Protocol Version = 2 => 0b10
Signed Flag = 0 => 0b0
Length of Payload = 1 = 0b00001

Which results in 0b10 0 00001 = 0b10000001

But I get this error:

LEN,8!=23

So .. where might this come from?

radio.write(test,8);

Mycontroller received a packet with the length of 8 but expected a packet with the length of .. 23 ?!

#define mGetLength(_message) ((uint8_t)BF_GET(_message.version_length, 3, 5)) //!< Get length field

Which in essential is BF_GET ..

#define BF_GET(y, start, len)   ( ((y)>>(start)) & BIT_MASK(len) ) //!< Extract a bitfield of length 'len' starting at bit 'start' from 'y'

So what is happening?

BF_GET(0b10000001, 3, 5)   ( ((0b10000001)>>(3)) & BIT_MASK(5) ) //!< Extract a bitfield of length 'len' starting at bit 'start' 

Whoops? This will throw away all the length-information!!!
(0b10000001)>>(3)
This should result in:
0b11110000 & BIT_MASK5 = 0b1111000 & 0b00011111 = 0b00010000 = 16 decimal

const uint8_t expectedMessageLength = HEADER_SIZE + (mGetSigned(_msg) ? MAX_PAYLOAD : msgLength);

const uint8_t expectedMessageLength = 7+ 16); // = 23

Yeah .. the lib is right .. 8 != 23 .. but the handcrafted length = 1 + header_length (7) = 8

Am I wrong or is this a bug?

Edit: I might have read the comments in the source code the wrong way

After many hours trial and error I present you .. the raw-mysensors-client!!

MyGateway: ESP8266 + mysensorsMQTT
MyNode: https://github.com/Miceuz/PlantWateringAlarm
MyNode-MCU: Attiny44 (MemoryFootprint: 87% of 4KB)
ArduinoCore: https://github.com/SpenceKonde/ATTinyCore
ArduinoCore-PinLayout: Counterclockwise (like AttinyCore)
Note: The default "counterclockwise"pinout is the alternate pinout shown here: https://github.com/SpenceKonde/ATTinyCore/blob/master/avr/extras/ATtiny_x4.md

The important hint is here (http://tmrh20.github.io/RF24/ATTiny.html)

Connect MOSI of the RF24 to PA5 of the attiny and MISO of the RF24 to PA6 of the attiny.
CE = 8
CSN = 7

To get the connection done right DONT .. i mean DO NOT BECAUSE IT DOESNT FUCKING WORK connect MOSI of the RF24 to MOSI of the attiny. RF24 uses a embedded implementation of the USI-engine found on some AtTiny's.

radio-initilisation

    radio.begin(); // Start up the radio
    radio.setDataRate(RF24_250KBPS);
    radio.setAutoAck(1); // Ensure autoACK is enabled
    radio.setRetries(15,15); // Max delay between retries & number of retries
    //radio.setPayloadSize(8);
    radio.enableDynamicPayloads();
    radio.setPALevel(RF24_PA_MAX);
    byte tx_address[] = { 0x00, 0xFC, 0xE1, 0xA8, 0xA8 };
    //byte tx_address[] = { 0xA8, 0xA8, 0xE1, 0xFC, 0x00 };
    radio.openWritingPipe(tx_address);
    radio.stopListening();

Send-Function:

void sendHumidity(uint16_t humidity)
{
    // snprintf_P(_fmtBuffer, MY_GATEWAY_MAX_SEND_LENGTH, PSTR("%s/%d/%d/%d/%d/%d"), prefix, message.sender, message.sensor, mGetCommand(message), mGetAck(message), message.type);
    // X8X22<\0><\n>!<7>7AY0;255;3;0;9;TSF:MSG:READ,50-50-0,s=55,c=1,t=7,pt=1,l=1,sg=0:65<\n>
    // 0;255;3;0;9;Sending message on topic: domoticz/in/MyMQTT/50/55/1/0/7<\n>
    
    #define LAST_NODE_ID  50  // last
    #define NODE_ID       50  // sender
    #define GATEWAY_ID    0   // destination
    
                              // version_length     // 5 bit - Length of payload // 1 bit - Signed flag // 2 bit - Protocol version
                              // command_ack_payload // 3 bit - Payload data type // 1 bit - Is ack messsage - Indicator that this is the actual ack message. // 1 bit - Request an ack - Indicator that receiver should send an ack back. // 3 bit - Command type
    
    #define SENSOR_TYPE   7   // type S_HUM = 7
    #define SENSOR_ID     55  // sensor-id
    byte test[] = { LAST_NODE_ID, NODE_ID, GATEWAY_ID, 0b00010010, 0b01100001,  SENSOR_TYPE, SENSOR_ID, (uint8_t)(humidity & 0x00FF), (uint8_t)((humidity >> 8) & 0x00FF),  0x00 };
    radio.write(test,9);
}

I am not quite sure yet if the message-types etc. are right but I am trying to find this out. 'A' (dec 65) is the "value" of my humidity .. next step is to make this a real value ofc.

Proof at domoticz:

@gohan: In the file MyConfig.h I commented this out:

/**
 * @def MY_REGISTRATION_FEATURE
 * @brief If enabled, node has to register to gateway/controller before allowed to send sensor data.
 */
// #define MY_REGISTRATION_FEATURE

This will skip the whole hasse of registering the client properly (which I can't .. remember 87% of flash is full)

@gohan Thanks for your response. The problem is that I already have 5 "chirps" and just later came up with the idea of adding nrf24 to them. I might try to add a "relay" node which will listen for "normal" rf24 packets and then send them to my gateway using the mysensors library.

Hello,

is it possible to "inject" a sensor-value into the gateway by hand-crafting a data packet?

I recently got some of these little guys (https://wemakethings.net/chirp/)

Now my idea was to slap a NRF24 on the ISP header (+2 extra pins for CE and CSN).

So far so good .. now I want to craft a simple packet to get data to my gateways ..

This is what I got so far but my gateway is not picking up anything.

    radio.begin(); // Start up the radio
    radio.setDataRate(RF24_250KBPS);
    radio.setAutoAck(1); // Ensure autoACK is enabled
    radio.setRetries(15,15); // Max delay between retries & number of retries
    byte station_address[] = { 0x00, 0xFC, 0xE1, 0xA8, 0xA8 };
    //byte station_address[] = { 0xA8, 0xA8, 0xE1, 0xFC, 0x00 };
    radio.openWritingPipe(station_address); // Write to device address 0x00,0xFC,0xE1,0xA8,0xA8
    radio.stopListening();
    byte test[] = { 250, 250, 0, 0b10000001 /* version_length */, 0b00100001,  7 /* S_HUM */ , 1 /* V_HUM */, 123};
    radio.write(test,8);

And no .. I can't cram the mysensors library on the ATTINY44.

I am currently happe that I got the basic chirp functunality for measuring the humidity of the soil, attiny debug serial and nrf24 all running on 4k of flash.

Der Sketch verwendet **4046 Bytes (98%)** des Programmspeicherplatzes. Das Maximum sind 4096 Bytes.
Globale Variablen verwenden 150 Bytes (58%) des dynamischen Speichers, 106 Bytes für lokale Variablen verbleiben. Das Maximum sind 256 Bytes.

If anybody know if this is even possible I would like to hear from you.

Best regards Marc

@NeverDie: In addition to using RF24_PA_MIN I power most of my nodes from 2x AA Alkaline Batteries .. so they have 2.2V - 3,0V VCC. This might contribute to my pretty good reception.

Earlier nodes used 3,3V LDO in connection with lithium-ion batteries. So I can't say what really improved my reception the most ... lowering the voltage or putting the RF24_PA_MIN.

Just to add my 2cent .. I mainly use the LNA+PA ones (cheap from ebay) and complained some time for their "bad" performance.

Just recently I noticed they are quite nice but .. RF24_PA_MIN is your friend! I got nearly zero packet-loss ~20m (one wall between) with RF24_PA_MIN. This might just be a subjective opinion but as they only cost 2-3$ a piece they are a good option (at least for me).

Getting "genuin" chips for a reasonable price is very difficulty in germany.

At least in theory .. how much power does the ultrasonic-part consume and/or do you switch it off between measurements?

19 days ago .. I hope i dont wake the dead .. on my latest projects I bagen using this nice stuff:

http://www.hornbach.de/shop/Hartschaumplatte-3x250x500-mm-schwarz/3888008/artikel.html

I currently have 5 modules of the "old"-jboard and still 2-3 spare "high"-power modules left. I just recently noticed that most of my communication problems apparently came from RF24_PA_MAX settings. Currently running with RF24_PA_MIN I am very satisfied with the "high"-power modules. Was just inrested int he latest developement.

My recent focus switched over to make some nice housings for my nodes. Having a board+sensors is only half of the work

Currently I mostly use Alkaline but on some project I use old handy-lipo-batteries. They are nice since they include some basic safety circuits.

Most of my projects work on 2xAA-Alkaline with 1mhz-AVR .. pretty good experience so far .. even with uses ones.

Are these new boards compatible to the old footprint? I think the layout of the "high power"-rf24 versions did not change in the past coulpe of years and I can't rely on the "small"-boards .. got a solid home with conrete falls

Its not like "defaultish"-library but currently I am using this piece:

https://github.com/fschaefer/Prescaler/blob/master/prescaler.h

It features some code to get the "real" millis but all librarys that depend on arduino "delay" and "millis" function might do wrong delays/timings.

All my nodes run at 1mhz to power them up with even 2xAA batteries @2,4volt or less. If some nodes have a more stable supply I use the library this way:

    uint8_t old_ps = getClockPrescaler();
    setClockPrescaler(0x00);
    oled.setCursor(0,1);
    oled << mymin << "," << sum << "," << mymax << "," << (diff < 1024 ? diff : 1024) << "," << (acc < 1024 ? acc : 1024) << " " << endl;
    oled << "sf: "  << spike_forgiveness << " " << endl;
    oled.setCursor(64,3);
    oled.print(readVcc());
    oled.print("mV  ");
    oled.setCursor(0,3);
    oled.print(RF24_readByteRegister(OBSERVE_TX),HEX);
    setClockPrescaler(old_ps);

Regarding the power-footprint. Are you using the sleep-function of mysn?

@tekka Thanks, that is what I was looking for

@Yveaux While we are at this topic .. any chance to let the user-code know what caused the wakeup during sleep() ??

For example .. if there was a wakeup at all or which of the two interrupt sources was the cause.

Unforunatly the "cause" gets cleaned up at the end of hwSleep:

bool interruptWakeUp()
{
    return _wokeUpByInterrupt != INVALID_INTERRUPT_NUM;
}

Calling this from user-code will always return 0 as the end of hwSleep does this:

 _wokeUpByInterrupt = INVALID_INTERRUPT_NUM;

Not clearing the "last interrupt source" would be nice.

I only used the pin change interrupt in another sketch. I was doubting Serial in sections without isr too! But they are clever. Serial output depends on polling in sections where interrupts are disabled

Just copy'pasted your fix and .. voila

Problems seems to be solved - although I do not unterstand why?!

• _wakeUp2Interrupt should be totally unrelated as it is never set
• detach should happen in the ISR

.. even if the interrupt is not detached correctly .. how should it lead to the total skip of these code:

	cli();
	wdt_reset();
	// enable WDT changes
	WDTCSR |= (1 << WDCE) | (1 << WDE);
	// restore saved WDT settings
	WDTCSR = WDTsave;
	Serial.println("sei()");
	Serial.flush();
	sei();
	// enable ADC
	ADCSRA |= (1 << ADEN);
	//WDTCSR |= (1 << WDIE); // set the WDIE flag to enable interrupt callback function.

As this code-snipped is skipped sei() gets never called in my case .. and the subsequent call to i2c freezes the node ... as i2c depends on interrupts ..

Anyway thanks Yveaux .. althour your fix is simple .. i don't know why it is working ...

EDIT: Furthermore .. even if the interrupt is not detached in the isr .. there should be no further interrupt if the interrupt register is not read via i2c .. and that in fact doesn't happen >:>

Jep, this is the library.

https://github.com/mysensors/MySensors/blob/development/core/MyHwATMega328.cpp#L86
https://github.com/mysensors/MySensors/blob/master/core/MyHwATMega328.cpp#L75

well .. I have no idea but on my code it is there:

Seems to be neither in the stable nor the developement branch .. but I most gotten it somewhere .. lets check

I think I added it for some reason on latest stable. Otherwise pinchage-interrupt was not working with mysensors-library .. I will try to remove it on stable to see if I get stuck there too and add in snapshot to see if it helps in some way.

EDIT1: Adding in the latest snapshot doesn't change a thing
EDIT2: Removing it in the latest stable doesn't change a thing

I might have added it from another testsketch .. but it would be better located in that sketch right after the sleep function .. so just ignore it for now - my bad ;_(

Comparing the code to the atmel documentation here:

http://www.atmel.com/webdoc/AVRLibcReferenceManual/group__avr__sleep.html

mysensors explicit disables interrupts after wake from sleep:

	sei();
	
    // Directly sleep CPU, to prevent race conditions! (see chapter 7.7 of ATMega328P datasheet)
	sleep_cpu();
    sleep_disable();	
	// restore previous WDT settings
	cli();

whereas the atmel documentation enables interrupts

#include <avr/interrupt.h>
    #include <avr/sleep.h>

...
  set_sleep_mode(<mode>);
  cli();
  if (some_condition)
  {
    sleep_enable();
    sleep_bod_disable();
    sei();
    sleep_cpu();
    sleep_disable();
  }
  sei();

Might not be totally related as the code did not change from last stable .. except one line:

	WDTCSR |= (1 << WDIE); // set the WDIE flag to enable interrupt callback function.

is now missing in the snapshot ..

Adding an extra sei() after the sleep_disable() is not the solution .. still thought it might be noteworthy

I got suspecious about the code working with the manual adding of sei() before calling the i2cread-function.

So I changed the end of hwPowerDown to include a serial output with a flush.

	// restore saved WDT settings
	WDTCSR = WDTsave;
	Serial.println("sei()");
	Serial.flush();
	sei();
	// enable ADC
	ADCSRA |= (1 << ADEN);
}

Now have a close look at how sei()-output is missing just before the freeze:

57114 MCO:SLP:TPD<\n>
sei()<\r><\n>
57147 MCO:SLP:WUP=-1<\n>
 | 57180<\r><\n>
57180 TSF:MSG:READ,0-0-14,s=0,c=1,t=16,pt=2,l=2,sg=0:0<\n>
57245 TSF:MSG:ACK<\n>
157262 TSF:MSG:SEND,14-14-0-0,s=0,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=OK:0<\n>
readI2cgot # from slave: 1<\r><\n>
r57376 MCO:SLP:MS=16,SMS=0,I1=1,M1=3,I2=255,M2=255<\n>
57442 MCO:SLP:TPD<\n>
sei()<\r><\n>
57475 MCO:SLP:WUP=-1<\n>
 | 57491<\r><\n>
57507 TSF:MSG:READ,0-0-14,s=0,c=1,t=16,pt=2,l=2,sg=0:0<\n>
57573 TSF:MSG:ACK<\n>
157589 TSF:MSG:SEND,14-14-0-0,s=0,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=OK:0<\n>
readI2cgot # from slave: 1<\r><\n>
r57704 MCO:SLP:MS=16,SMS=0,I1=1,M1=3,I2=255,M2=255<\n>
57769 MCO:SLP:TPD<\n>
57786 MCO:SLP:WUP=1<\n>
 | 57786<\r><\n>
57786 TSF:MSG:READ,0-0-14,s=0,c=1,t=16,pt=2,l=2,sg=0:0<\n>
57786 TSF:MSG:ACK<\n>
157786 TSF:MSG:SEND,14-14-0-0,s=0,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=OK:0<\n>
readI2c

Just after "57769 MCO:SLP:TPD<\n>" the sei()-output is missing. Thus I suspect that interrupts are not enabled when the readI2c-function is called .. and as i2c is depending on interrupts the code gets stuck there.

Still no idea why the sei() is "sometimes" not called ...

Notice how the "millis" interrupt is not called after the missing sei .. thus all timestamps are the same:

57786 MCO:SLP:WUP=1<\n>
 | 57786<\r><\n>
57786 TSF:MSG:READ,0-0-14,s=0,c=1,t=16,pt=2,l=2,sg=0:0<\n>
57786 TSF:MSG:ACK<\n>
157786 TSF:MSG:SEND,14-14-0-0,s=0,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=OK:0<\n>
readI2c

Code working: (4minutes+)

  sei();
  fabo3axis.readIntStatus();

Code not working:

  //sei();
  fabo3axis.readIntStatus();

I noticed that interrupts in the sleep function are only detached if the intrrupt occurs ..

whereas in the stable

	detachInterrupt(interrupt1);
	if (interrupt2!=0xFF) detachInterrupt(interrupt2);

They get detached after the wakeup in the sleep ..

What if .. for some strange reason the interrupt is interfearing with .. whatever?!

EDIT: with the added sei(); the node is running for 10 minutes now ...
EDIT2: Running for 20 minutes now ..

That would be nice .. my latest findings point out that the i2c-function is getting stuck. I investigated the i2c-source of arduino a bit and found out it is quite depending on interrupts.

This is now

wild speculation

For some reason interrupts got disabled while the i2c library is trying to write some data on the i2c-bus ..

wild-speculation-end

@1.6.12 board defs

r68550 MCO:SLP:MS=16,SMS=0,I1=1,M1=3,I2=255,M2=255
68599 MCO:SLP:TPD
68632 MCO:SLP:WUP=1
 | 68632
68632 TSF:MSG:READ,0-0-14,s=0,c=1,t=16,pt=2,l=2,sg=0:0
68632 TSF:MSG:ACK
168632 TSF:MSG:SEND,14-14-0-0,s=0,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=OK:0
readI2c

@1.6.13 board defs

readI2cgot # from slave: 1
r62914 MCO:SLP:MS=16,SMS=0,I1=1,M1=3,I2=255,M2=255
62980 MCO:SLP:TPD
62996 MCO:SLP:WUP=1
 | 62996
62996 TSF:MSG:READ,0-0-14,s=0,c=1,t=16,pt=2,l=2,sg=0:0
62996 TSF:MSG:ACK
162996 TSF:MSG:SEND,14-14-0-0,s=0,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=OK:0
readI2c

btw .. the "old" library is running happy for 6 minutes now ... still continuing

TSP:MSG:READ 0-0-14 s=0,c=1,t=16,pt=2,l=2,sg=0:0
1TSP:MSG:SEND 14-14-0-0 s=0,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=ok:0
readI2cgot # from slave: 1
r | 373997
TSP:MSG:READ 0-0-14 s=0,c=1,t=16,pt=2,l=2,sg=0:0
1TSP:MSG:SEND 14-14-0-0 s=0,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=ok:0
readI2cgot # from slave: 1
r | 374177

@tekka: I will try the "new snapshot" with the board defs you mentioned .. standby

yeah .. sorry

@tekka said:

AVR board def

What do you mean with AVR board def?

https://forum.mysensors.org/topic/4999/latest-git-snapshot-causes-freezes/17

I am using an arduino pro-mini china clone (328p) with 8mhz internal oscillator and DIV_8 fuse.

The bootloader is an "APM Optiboot 1Mhz" .. cant find the link right now.

@scalz Thanks for the hint with the while-loop. I changed the i2c-read the following way:

void FaBo3Axis::readI2c(uint8_t register_addr, uint8_t num, uint8_t buffer[])
{
  Wire.beginTransmission(_i2caddr);
  Wire.write(register_addr);
  Wire.endTransmission();

  Wire.requestFrom(_i2caddr, num);

  int i = 0;
  uint8_t limit = num;
  while(Wire.available() && limit--)
  {
	Serial.print("r");
    buffer[i] = Wire.read();
    i++;
  }
}

Now it should under no circumstanced read more then the number given. Sadly this had no impact:

 | 34291
34291 TSF:MSG:READ,0-0-14,s=0,c=1,t=16,pt=2,l=2,sg=0:0
34357 TSF:MSG:ACK
134390 TSF:MSG:SEND,14-14-0-0,s=0,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=OK:0
r34471 MCO:SLP:MS=16,SMS=0,I1=1,M1=3,I2=255,M2=255
34537 MCO:SLP:TPD
34553 MCO:SLP:WUP=1
 | 34553
34553 TSF:MSG:READ,0-0-14,s=0,c=1,t=16,pt=2,l=2,sg=0:0
34553 TSF:MSG:ACK
134553 TSF:MSG:SEND,14-14-0-0,s=0,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=OK:0

Just before the sleep ..

I then added a Serial.flush() to the "r"-output ..

void FaBo3Axis::readI2c(uint8_t register_addr, uint8_t num, uint8_t buffer[])
{
	Serial.print("readI2c");
	Serial.flush();
  Wire.beginTransmission(_i2caddr);
  Wire.write(register_addr);
  Wire.endTransmission();

  Wire.requestFrom(_i2caddr, num);

  int i = 0;
  uint8_t limit = num;
  while(Wire.available() && limit--)
  {
	Serial.print("r");
	Serial.flush();
    buffer[i] = Wire.read();
    i++;
  }
}

54706 MCO:SLP:WUP=1
 | 54706
54706 TSF:MSG:READ,0-0-14,s=0,c=1,t=16,pt=2,l=2,sg=0:0
54706 TSF:MSG:ACK
154706 TSF:MSG:SEND,14-14-0-0,s=0,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=OK:0

Now the freeze is clearly before entering the sleep function ..

but then .. on another round ..

 | 56623
56623 TSF:MSG:READ,0-0-14,s=0,c=1,t=16,pt=2,l=2,sg=0:0
56623 TSF:MSG:ACK
156623 TSF:MSG:SEND,14-14-0-0,s=0,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=OK:0
readI2c

readI2cgot # from slave: 1
r78987 MCO:SLP:MS=16,SMS=0,I1=1,M1=3,I2=255,M2=255
79052 MCO:SLP:TPD
79069 MCO:SLP:WUP=1
 | 79069
79069 TSF:MSG:READ,0-0-14,s=0,c=1,t=16,pt=2,l=2,sg=0:0
79069 TSF:MSG:ACK
179069 TSF:MSG:SEND,14-14-0-0,s=0,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=OK:0
readI2c

So .. your tip was very good .. it seems to be related to the

  Wire.beginTransmission(_i2caddr);
  Wire.write(register_addr);
  Wire.endTransmission();

-call .. only one questions remains .. why was it working perfectly on the stable library?

Just to be sure I will run exactly the same code in a non-stop loop with the stable library ..

@tekka Arduiono 1.6.12

##############################################################
# Add the new board to boards.txt (normally located at "C:\Program Files\Arduino\hardware\arduino\avr"
# The *.bootloader.* etries only matters if you want to program bootloader (and fuses) from Arduino IDE. 
# See http://www.engbedded.com/fusecalc (select Atmega328p) for interpretation of fuse values and how 
# extended fuses are written in different applications (07h in Arduino IDE = FFh in Atmel studio).
##############################################################

apm96.name=APM Optiboot internal 1MHz noBOD 9600baud

apm96.upload.tool=avrdude
apm96.upload.protocol=arduino
apm96.upload.maximum_size=32256
apm96.upload.speed=9600
apm96.bootloader.tool=avrdude
apm96.bootloader.low_fuses=0x62
apm96.bootloader.high_fuses=0xde
apm96.bootloader.extended_fuses=0x06
apm96.bootloader.path=optiboot_v50
apm96.bootloader.file=atmega328_1a.hex
apm96.bootloader.unlock_bits=0x3F
apm96.bootloader.lock_bits=0x2F
apm96.build.board=AVR_APM96
apm96.build.mcu=atmega328p
apm96.build.f_cpu=1000000L
apm96.build.core=arduino
apm96.build.variant=standard

##############################################################

I changed the fuses to include BDOUT @ 1,8Volt
VCC of my setup is 2-3Volt

@ikkeT Are you using the latest stable or snapshot version?

I noticed that I can make the node crash if I trigger some interrupts by force (moving the accelerometer) .. nice ..

I guess the sleep/interrupt code has some kind of bug since the latest rework in the developer branch.

no sleep = fine
no i2c-communiction/no interrupts = fine

both = lockup

// http://www.earth.org.uk/OpenTRV/Arduino/bootloader/ATmega328P-1MHz/README.txt
#define MY_NODE_ID 14

#define MY_BAUD_RATE 9600 // DONT GO HIGHER AS 57600 !!! 115200 might cause DEADLOCKS!!!

// Enable debug prints to serial monitor
#define MY_DEBUG
#define MY_DEBUG_LIGHT

#define MY_RF24_PA_LEVEL RF24_PA_HIGH

// Enable and select radio type attached
#define MY_RADIO_NRF24
//#define MY_RADIO_RFM69

#include <SPI.h>
#include <MySensors.h>
//#include "helper.h"

//MySensorChild motionSensor = MySensorChild(0, S_MOTION, V_TRIPPED, "");

void before()
{
  //wdt_enable(WDTO_8S);
}

void presentation()
{
  // Send the sketch version information to the gateway and Controller
  char datetime[30]; // 22 + 1 should ben enough
  snprintf(datetime, 30, "%s | %s", __DATE__, __TIME__);
  #ifdef MY_DEBUG_LIGHT
  Serial.print(F("SketchInfo: "));
  Serial.println(datetime);
  #endif

  sendSketchInfo("adxl345", datetime);
}

#include <Wire.h>
#include <FaBo3Axis_ADXL345.h>

FaBo3Axis fabo3axis;

//void ADXL_ISR()
//{
//
//}

void setup()
{
  Serial.begin(9600); // シリアルの開始デバック用
  
  Serial.println("Checking I2C device...");
  
  //if(fabo3axis.searchDevice()){
  //  Serial.println("I am ADXL345");
  //}
  Serial.println("Init...");
  
  fabo3axis.configuration();
  fabo3axis.powerOn();
  //fabo3axis.enableTap();
  fabo3axis.enableActivity();
  //attachInterrupt(digitalPinToInterrupt(3), ADXL_ISR, RISING);
  fabo3axis.readIntStatus();
  
  // http://www.avrfreaks.net/forum/wire-library-increasing-i2c-speed
  //TWBR = ((F_CPU / 400000) - 16) / 2;
  TWBR = 0;
  Serial.print("i2c @ "); Serial.print(TWBR); Serial.println(); 
}


void loop() { 
  //wdt_reset();
  MyMessage msg(0, V_TRIPPED);
  //motionSensor.set(1);  motionSensor.waitsend(50);
  //send(msg,true);
  
  //uint8_t s = fabo3axis.readIntStatus();
  uint8_t s = 1;
  if(false){
    Serial.print("activity ");
    //Serial.println(millis());
    msg.set(1);
    send(msg,true);
    //motionSensor.set(1);  motionSensor.waitsend(50,60000);
  }
  else
  {
    Serial.print(s,HEX);
    msg.set(0);
    send(msg,true);
    //motionSensor.set(0);  motionSensor.waitsend(50,60000);
  }
  
  //Serial.println("prepare to sleep");
  Serial.flush();
  
  // Pending Int-Stati might prevent interrupt!
  fabo3axis.readIntStatus();
  sleep(digitalPinToInterrupt(3),RISING,16);

  //millis_offset += 16;
  Serial.print(" | ");
  Serial.println(hwMillis());
}

bool my_ack_received;
void receive(const MyMessage &message)
{
  if (message.isAck())
    my_ack_received = true;
}

I suspect the sleep/interrupt combination.

Could not remove the accelerometer cause it is the source of the interrupts

Okay ... I switched back between snapshot from yesterday and stable 2.0.0 and all I can say is that the stable is perfectly fine and the snapshot freezes.

prepare to sleep
17416 MCO:SLP:MS=16,SMS=0,I1=1,M1=3,I2=255,M2=255
17481 MCO:SLP:TPD
17498 MCO:SLP:WUP=1
.18

Nothing on the code has been changed. Only difference is that I had to modifie latest stable to include a few delays for my slow 1mhz node ..

PS: I currently don't have the time to debug this issue further .. last time it took me some days to figure out the delay-issue of slow nodes ...

I forgot to mention that the node is battery powered @ 2x AA-Alkaline-Battery @ ~2,5volt .. no LDO involved .. and an NRF24+LNA+PA version of the NRF24 ..

I got like 4-5 boards with this exact same setup and they run totally fine with the latest stable release ..

.. investigating the root cause might be difficulty as my code is a little bit customized with a little wrapper .. will try out a fresh sketch tomorrow ..

and .. again ..

.79366<\r><\n>
Update<\r><\n>
76038 TSF:MSG:SEND,14-14-0-0,s=0,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=OK:1<\n>
 | hwretry: 0<\r><\n>
76038 TSF:MSG:READ,0-0-14,s=0,c=1,t=16,pt=2,l=2,sg=0:1<\n>
76038 TSF:MSG:ACK<\n>

My loop currently looks like this:

void loop() { 

  motionSensor.set(1);  motionSensor.waitsend(50);
  /*
  uint8_t s = fabo3axis.readIntStatus();
  if(ADXL345_INT_ACTIVITY & s){
    Serial.print("activity ");
    Serial.println(millis());
    motionSensor.set(1);  motionSensor.waitsend(50);
  }
  else
  {
    Serial.println(s,HEX);
    motionSensor.set(0);  motionSensor.waitsend(50);
  }
  */
  Serial.println("prepare to sleep");
  Serial.flush();
  
  // Pending Int-Stati might prevent interrupt!
  //fabo3axis.readIntStatus();
  sleep(digitalPinToInterrupt(3),RISING,16);
  
  // helper.h
  //extern unsigned long millis_offset;
  millis_offset += 16;
  Serial.print(".");
  Serial.println(mymillis());
}

All referencec to the acceleration sensor removed .. the interrupt should not trigger as the interrupt-register is not "cleard" by issuing the readIntStatus ..

And again ...

145440 MCO:SLP:MS=16,SMS=0,I1=1,M1=3,I2=255,M2=255<\n>
145489 MCO:SLP:TPD<\n>
145522 MCO:SLP:WUP=1<\n>
.152002<\r><\n>
Update<\r><\n>
145522 TSF:MSG:SEND,14-14-0-0,s=0,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=OK:1<\n>
 | hwretry: 1<\r><\n>
145522 TSF:MSG:READ,0-0-14,s=0,c=1,t=16,pt=2,l=2,sg=0:1<\n>
145522 TSF:MSG:ACK<\n>

But this time at a differenct part ...

  fabo3axis.readIntStatus();
  sleep(digitalPinToInterrupt(3),RISING,16);

Removing this as well ..

Okay .. I am currently investigating:

TWBR = 0;

Might be somehow related as removing it causes no hangups so far...maybe I am seeing things with the newest snapshots Strangely the code was working fine until I added the mysensor-part ...

wopps .. again

264077 TSF:MSG:READ,0-0-14,s=0,c=1,t=16,pt=2,l=2,sg=0:0<\n>
264142 TSF:MSG:ACK<\n>
prepare to sleep<\r><\n>
264208 MCO:SLP:MS=16,SMS=0,I1=1,M1=3,I2=255,M2=255<\n>
264273 MCO:SLP:TPD<\n>
264290 MCO:SLP:WUP=1<\n>
.30

So i2c-speed is probably unrelated .. as even after commeting the TWBR = 0; out the hangup repeated.

Next I will try to remove the acceleration-sensor readings ...

Only thing I can say so far is that this method-call causes the freez:

Hardware setup:

• node = 1mhz arduino pro mini (internal osciallator) with jboard and nrf24
• gateway = esp8266

the node is connected to an i2c adxl345 acceleration sensor

 send(_message,true);

prepare rssi<\r><\n>
12075 TSF:MSG:SEND,14-14-0-0,s=1,c=1,t=28,pt=0,l=11,sg=0,ft=0,st=OK:rssi: 8|0|2<\n>
Update<\r><\n>
12173 TSF:MSG:SEND,14-14-0-0,s=0,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=OK:0<\n>
 | hwretry: 0<\r><\n>
12255 TSF:MSG:READ,0-0-14,s=0,c=1,t=16,pt=2,l=2,sg=0:0<\n>
12320 TSF:MSG:ACK<\n>
prepare to sleep<\r><\n>
12369 MCO:SLP:MS=16,SMS=0,I1=1,M1=3,I2=255,M2=255<\n>
12419 MCO:SLP:TPD<\n>
12435 MCO:SLP:WUP=1<\n>
12

Gateway

0;255;3;0;9;TSF:MSG:SEND,0-0-14-14,s=0,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=OK:0<\n>
0;255;3;0;9;Sending message on topic: mygateway-out/14/0/1/0/16<\n>
0;255;3;0;9;TSF:MSG:READ,14-14-0,s=0,c=1,t=16,pt=2,l=2,sg=0:0<\n>
0;255;3;0;9;TSF:MSG:ACK REQ<\n>
0;255;3;0;9;TSF:MSG:SEND,0-0-14-14,s=0,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=OK:0<\n>
0;255;3;0;9;Sending message on topic: mygateway-out/14/0/1/0/16<\n>
0;255;3;0;9;TSF:MSG:READ,14-14-0,s=0,c=1,t=16,pt=2,l=2,sg=0:0<\n>
0;255;3;0;9;TSF:MSG:ACK REQ<\n>
0;255;3;0;9;TSF:MSG:SEND,0-0-14-14,s=0,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=OK:0<\n>
0;255;3;0;9;Sending message on topic: mygateway-out/14/0/1/0/16<\n>
0;255;3;0;9;Sending message on topic: mygateway-out/0/0/1/0/15<\n>
0;255;3;0;9;Sending message on topic: mygateway-out/0/0/1/0/15<\n>

whole project:

node-debug-log:0_1475363295558_adxl345_vibrationtest_fabo_rf.rar

You can see that the output stops while flushing an millis output ...

I am using my own milliseconds-wrapper but this should make no difference. I can say that the freezes occurs within 1-5minutes with the setup from the attached file.

I speed up the process of the loop to better reproduce the error. I noticed that the hangup occurs somewhere during the end of the loop. In addition to that he freeze does not occur if I send no messages to the gateway/controller at all but do only internal processing.

Tomorrow I might clean up my sketch and try a minimal setup and reproduce the hangup.

One possibility I am looking into is a interference of:

TWBR = 0;

At the same time I got a random gateway crash:

0;255;3;0;9;Sending message on topic: mygateway-out/14/0/1/0/16<\n>
Fatal exception 28(LoadProhibitedCause):<\n>
epc1=0x402026ac, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00000003, depc=0x00000000<\n>
<\r><\n>
Exception (28):<\r><\n>
epc1=0x402026ac epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000003 depc=0x00000000<\r><\n>
<\r><\n>
ctx: cont <\r><\n>
sp: 3ffef980 end: 3ffefbe0 offset: 01a0<\r><\n>
<\r><\n>
>>>stack>>><\r><\n>
3ffefb20:  00000000 3ffeff7c 3ffefdc4 4020589f  <\r><\n>
3ffefb30:  001e8480 00085f6b 3ffefdc4 40202f98  <\r><\n>
3ffefb40:  00000001 00000011 00000000 3ffeebac  <\r><\n>
3ffefb50:  3fffdad0 00085f6b 3ffefc8c 40203282  <\r><\n>
3ffefb60:  3fffdad0 00085f6b 3ffefc8c 40203bb8  <\r><\n>
3ffefb70:  3fffdad0 00085f6b 0000ea60 402031bd  <\r><\n>
3ffefb80:  3fffdad0 00085f6b 0000ea60 4020463d  <\r><\n>
3ffefb90:  3fffdad0 00000000 0000ea60 4020465e  <\r><\n>
3ffefba0:  00000001 00000000 0000ea60 40204683  <\r><\n>
3ffefbb0:  00000000 00000000 3ffeeb80 40204b49  <\r><\n>
3ffefbc0:  3fffdad0 00000000 3ffeeb80 40204d83  <\r><\n>
3ffefbd0:  feefeffe feefeffe 3ffeebc0 40100114  <\r><\n>
<<<stack<<<<\r><\n>
<\r><\n>
 ets Jan  8 2013,rst cause:2, boot mode:(1,6)<\r><\n>
<\r><\n>
<\r><\n>
 ets Jan  8 2013,rst cause:4, boot mode:(1,6)<\r><\n>
<\r><\n>
wdt reset<\r><\n>

Can u describe more about your sensor node? What voltage? What speed? General setup?!

Nice to hear, keep the good work up!

@mfalkvidd

This might be the case. Thanks for the info .. i am looking forward to test it

@hek: Could you change the part with "Here is a quick summary of the config options available. NOTE: This table will be updated with more information shortly" to be collapsed at the beginning and a + to exapand? Currently this section takes a lot of space and as it is essential for beginners might frighten new users

@sundberg84

Be aware that depending on the mesurement range a multimeter could introduce a big burdan voltage.

Just simple and short: To measure in the mA range you the multmeter measures the voltage drop accross a series resistor with an value .. call it A.

Switching to the µA range the mutltimeter switches to a much larger resistor (e.g. 1000times A) to measure a significat enough voltage drop. With the wrong voltage range .. measuring µA while the board is consuming in the mA range might lead to a huge voltage drop and your circuit not working at all.

So do this:

• Switch to mA mode .. take your measurement .. wait until you KNOW for sure your circuit is in sleep mode (add some messages on the serial console) and THEN switch to µA range.

Before opening a new thread I would like to attach my question to this one.

I use sleep quite a lot and got the feeling that quite a lot of the time the first message sent after "waking" up is getting lost .. so here is my question:

What do I have to do after hitting sleep? I already noticed that sleep is a combination of:

transportPowerDown();

and

hwSleep

If there is nothing I have to do this might be pure imagination and I would have to track down the issue further. Thanks in advance!

What is your code doing after the presentation? I always use a little wait after the presentation as many rapid presentations might congest the gateway:

void presentation()
{ 
  // Send the sketch version information to the gateway and Controller
  char datetime[24]; // 22 + 1 should ben enough
  snprintf(datetime,24,"%s | %s",__DATE__,__TIME__);
  //Serial.print(F("SketchInfo: "));
  //Serial.println(datetime);
  
  sendSketchInfo("Microwave/Knocks.", datetime);
  mw_s_var1.present();
  wait(10);
  mw_s_var2.present();
  wait(10);

  /*
  ks_s_var1.present();
  wait(10);
  ks_s_var2.present();
  wait(10);
  */
}

I checked the sourcecode and it seems that only parts of the watchdog are implemented. I enabled the watchdog the following way:

At the beginning of the sketch #include <avr/wdt.h>

Later at

void before()
{
  wdt_disable(); // maybe redundant
  wdt_enable(WDTO_8S);

And finally at the loop

void loop()
{
  wdt_reset();

Advanced reading:

The sleep() method on mysensors does something special with the watchdog. It enabled the interrupt flag and defines an empty

// Watchdog Timer interrupt service routine. This routine is required
// to allow automatic WDIF and WDIE bit clearance in hardware.
ISR (WDT_vect)
{

}

When the Atmega328p engages sleep mode the watchdog timeout is overwritten with your designated sleep period. The watchdog then times out and calles the service routine (ISR). After the ISR-routine finished the interrupt flag is disabled. This leeds to an reset at the next imeout of the watchdog.

Normal reading again
Luckyly the sleep() routine is smart enough to save and restore your custom watchdog settings. When the watchdog times out (as the interrupt flag is not set) the Atmega328p resets. In the bootloader the watchdog is disabled until you enable it in the before()-Method again.

Well .. overwriting an !important doesn't seem to be this easy ..

The best I could come up with:

// ==UserScript==
// @name         New Userscript
// @namespace    http://tampermonkey.net/
// @version      0.1
// @description  try to take over the world!
// @author       You
// @match        https://forum.mysensors.org/*
// @grant        none
// ==/UserScript==

function addNewStyle(newStyle) {
    var styleElement = document.getElementById('styles_js');
    if (!styleElement) {
        styleElement = document.createElement('style');
        styleElement.type = 'text/css';
        styleElement.id = 'styles_js';
        document.getElementsByTagName('head')[0].appendChild(styleElement);
    }
    styleElement.appendChild(document.createTextNode(newStyle));
}

(function() {
    'use strict';
    // Your code here...
    addNewStyle('.container { width: 55% !important;}');
    //$(".container").removeAttr("width");
})();

Sorry for stirring up so you guys at this late hour .. but .. I only strive to improve mysensors (with my stupid comments and ideas :D) as I really like the library, the controller, the site

This is just "balm for the eyes" .. I can absolutelty life with tinkering with greasemoneky

@hek said:

#content div

Yep .. I am just heading for greasemonkey

I would be more happy with 10-15% but I think I can live with it. Would be even more awesome if this could be set as a "preference" on a per user basis .. but this would be too much to ask

PS: Can u tell me where you have added the padding? (in the css file?!)

@treborjm87 The fault is not with your cloes but .. well .. how should I put it .. the Watchdog on almost all "Arduino pro mini" clones from china is broken. Normally the watchdog gets disabled during bootloader (just after the reset) but on these clones the default bootloader dosn't do this .. leading to an infinite boot loop.

This issue can be solved by connecting an Arduino set up as ISP-Programmer and burning the current Arduino bootloader.

As the pro minis come unsoldered I made myself a little adapter consisting only of male pin headers where I can put the pro mini in. The pins are not connected very good but pressing the pro mini in place I can very easylie reflash the bootloader before I put them into my projects.

Just for the sake of linking the issue:

https://github.com/mysensors/MySensors/issues/581

@treborjm87 The Atmega328P has already an buildin hardware watchdog. It will reset your node if you don't feed it via

wdt_reset();

IP: 192.168.178.87<\r><\n>
0;255;3;0;9;Attempting MQTT connection...<\n>
IP: 192.168.178.87<\r><\n>
0;255;3;0;9;Attempting MQTT connection...<\n>
IP: 192.168.178.87<\r><\n>
0;255;3;0;9;Attempting MQTT connection...<\n>
IP: 192.168.178.87<\r><\n>
0;255;3;0;9;Attempting MQTT connection...<\n>
IP: 192.168.178.87<\r><\n>
0;255;3;0;9;Attempting MQTT connection...<\n>
IP: 192.168.178.87<\r><\n>
0;255;3;0;9;Attempting MQTT connection...<\n>
IP: 192.168.178.87<\r><\n>
0;255;3;0;9;Attempting MQTT connection...<\n>
IP: 192.168.178.87<\r><\n>
0;255;3;0;9;Attempting MQTT connection...<\n>
IP: 192.168.178.87<\r><\n>
0;255;3;0;9;Attempting MQTT connection...<\n>
IP: 192.168.178.87<\r><\n>
0;255;3;0;9;Attempting MQTT connection...<\n>

So yeah .. the mqttclient will try to reconnect until .. like ever I just tested it for like 30 seconds but I don't think there will be a "timeout".

Yeah .. "advanced build options" should in every case fit there

@hek: If this is your "real" screen size I can totally understand why this is no issue for you at all
It looks a "little bit" packed but still much more accessible then splitting. I want to search? Top right corner .. I want to read the most recent message? Top right .. wanne check download area? Guess what ..

I like your idea and I totally agree that breaking lines when there is enough space is not a good design.

And .. I would never ever use a mac

And you are right .. I can't tilt my screen and I am not willing to change my browser size for one tab out of ~25.

Even if it might be obvious .. if the title is too long to fit the layout .. maybe choose a shorter, more concisely title

So why not leave it and maybe add another 5-10% more space?

Or .. if you are in the mood to experiemnt .. why not add the menu to the right? This would allow it to take as much of the free space it needs.

To make this clear .. I am not saying "the new design is bad because .. reasons" .. I can only report my impression of as a user of a "big" screen (24" @ 1920x1080) and can say it feels awkwars when the content is split all over the screen .. having to constantly move my eyes over a large distance as the "relevant" and "important" functions are now split more then nessesary.

@Anticimex

You just made a point .. ever wondered why books are not printed in landscape? Because moving the eys from the right most side to the left most sides is a hassle and stressfull.

@hek

Point 1: I really like the idea of having the forum and main site menu united.

Now the important stuff is also split. Categories, unread .. and most popular on the left .. search and notifications on the right .. why not move all to the same side?

Point 2: I like the left menu. Nothing to comlain here.

Point 3:

Switching between the "starting page" and the "forum" now looks like a mayor break in the design flow

PS: The main page design is much more flexible with different sizes. If the monitor is smaller .. just take from the free space (left and right) .. if the monitor is bigger .. well .. some more free space .. nice.

But with the forum it is totally different. Pinning the content to the left and right space gives a different user experience depening on your resolution.

.. lets stay serious .. I don't know a sigle site on the interweb that is splitting the important stuff of the page to the left AND right side. It defies all ergonomical logic and in my oppinion is much worse then before.

If something is working ... why change it? Just because there is so much space on modern screens dosn't mean you have to arbitrarily try to fill it with some content.

I just picked 3 of the mayor forum software providers by random choice and they all have like

3-6-3 with their designs .. meaning 25% free space to the right and left of the screen.

http://www.vbulletin.com/forum/
http://www.try-phpbb.com/31x/viewforum.php?f=2&sid=7b6920e75c920daf0d22f90f466ad94a
https://community.woltlab.com/

Woltlab is filling the right side with some more general stuff .. still all have the same scheme.

Have you tried to enable #define MY_DEBUG and have a Serial terminal opened all the time?

Maybe you can get some clues on where the sketch "hangs up"

EDIT: Still you have this huge space in the middle and on the right side the text is wrapping ...

Tilt my screen! Genius idea!

But what will I do on .. like all the rest of the internet that have designed their pages the other way around?

I am using "defaultish" 16:9 1920x1080

Well .. I can partly understand this but .. I don't want to move my head either

I am not "pro" at web design but I would expect the most important part of a side centered in the mid .. not scattered over all the screen.

@Anticimex: scold .. give us the old design back!!! At least the part with narrow spacing.

Are you using the ESP8266 as your mqtt-client? If so this might help you.

https://github.com/esp8266/Arduino/issues/1532

If you are using an Atmega328 this is the code I am currently using.

#include <avr/wdt.h>

void before()
{
  wdt_disable(); // Might be redundant as the bootloader should have done this already
  wdt_enable(WDTO_8S);
....

void loop()
{
  wdt_reset();

I find the huge gap between the title and the #Post very .. annonying. Now I have to move my had from totally left of my screen to totally right to read the latest post for each topic.

Using Serial.begin(115200) I experienced some lockups of the atmega328p .. serial communication stopped completely as well as all other operation .. WTF ?!

Somehow the graph from the datasheet doesn't fit at all for my internal oscillator.

Just an example .. I programmed the fuse to output the clock on PortB0 and I got:

OSCCAL=66;
Serial.begin(57600);
~973 KHz

OSCCAL=66;
Serial.begin(115200);
~973 KHz

OSCCAL=240;
Serial.begin(250000);
~1.88 MHz

I would expect OSCCAL = 66 to get me ~ 6/8 = 800KHz

Update: I missed one important point .. OSCCAL doesn't range from 140 to 200 but actually from 0 to 255

I changed the ranges and ...

void setup() {
  Serial.begin(250000);
  Serial.println(OSCCAL);
}

// Use hterm to repeatatly send the same message unti you cacn read it
void loop() {
  static uint8_t val = 0;
  OSCCAL=val;
  //Serial.println();
  Serial.print("Osccal= ");  
  Serial.println(OSCCAL,DEC);

  delay(100);
  //while(Serial.available())
  //  Serial.write(Serial.read());
  val++;
  if(val > 250)
  {
    while(true);
  }
}

Believe it or not

Starting from osccal 239 .. which is technically 12/8 = 1,5mhz and not 1mhz .. I was able to receive some data .. with the drawback that all delay functions etc. might be "a little bit" off.

Wohoo .. 1,5mhz @ 250.000baud

Might be some artifact but .. it is still nice to know ^^

If you are sending lots of messages you might night to resort to the latgest snapshot.

https://github.com/mycontroller-org/mycontroller/issues/253#issuecomment-242132060

With the snapshot you might increase the "resoruce-log" level and decrease the retention time. (The resorucelog is a history of the most recent received message).

With 1Mhz I could get working was 115200.

I would like to switch to 8mhz but I have a dilemma.

I got ten 2xAA battery holders which would give me (with batteries) a working range from ~2.00V - 3.00V (approx).

The only option left is trying out the whole stuff with 16mhz / 8 = 2mhz but .. well .. I can't reflash the fuses on the jnode after assembly.

The other option I have is to switch to LDO + LiPo battery but I was not too sure to put lipo batteries all over my place for safety concerns. Don't know what will happen if on a hot summer day the lipo might get a full day of sun radiation when placed near a window for example.

@Yveaux

Ideally I would like to use something like this:

    template <typename T>
    T lastValue;

    template <typename T>
    bool ismyEq2(T a)
    {
      bool iseq = (a == lastValue);
      lastValue = a;
      return iseq;
    }

inside my class. But I learned that in C every variable has to be defined on compile time and this would not possible with lastValue.

Currently I am very happy with ismyEq as it currently is simply because it is working for now Still I am open for better options - maybe some fancy template tricky I don't know yet. (Overall I know very little about proper Template using).

if pyMYS doesn't suit you mycontroller might be an option too. (my sensor is not sending enough data for a very fast interval :D)

Its not "realtime" but mycontroller supports widgets with refresh rate with .. don't know .. as fast as the hardware can go? Fiddler seems to prove that with 0.1s refresh intervall on the widget the request from the webpage to the controller are made every 100ms.

I have no sensor to shop up some real usefull data but have a look.

@Yveaux

I am doing exactly the thing you proposed .. except I don't create a duplicate message. This function takes an arbitrary datetype and writes it to an 8-byte array.
Having two arrays I compare them both in the while-loop.

My goal is to have a very clean and slim loop in my sketch while having a very generic wrapper.
The wrapper includes sending and receiving and processing of the software ack (as my china counterfeight nrf24-modules dont't support hardware-autoack @ 250kbps). Furthermore I want to ensure that the message is not send too often (battery-node friendly) but at least every 32 seconds (example) or when the values changes from the last sent value.

void loop()
{
  // Reedsensor1
  reedSensor1.set(digitalRead(7));
  reedSensor1.waitsend(8,32); // Wait 8ms for response, otherwise retry, send max 1x every 32seconds
  
  sleep(2000);
  millis_offset += 2000;
}

@tekka

Update: https://github.com/mysensors/MySensors/issues/578#issuecomment-244421537

Have a look at the timing diagram

I am writing a little wrapper for mymessage to check some thinks like "When was the message send the last time?" and "Did the value change since the last update?"

Realizing the "complicated" way mysensor stores values it is very difficulty for me to find an function that works with all value-types.

Since I have to use a template for the equal-function and I apparently can't use static inside this function since I have differnt instances .. is there an easier way to check if the value changed since last time?

Currently I store the value in an 8byte array which should cope with all data types including float.
memcopy, memset and an short while-loop are hopefully not the most efficient way to do this.

And nope .. I don't want to store the last value in the loop ...

  private:
    byte _lastmsg[8];
    byte _currmsg[8];
    
    template <typename T>
    bool ismyEq(T a)
    {
      //Serial.print("ismyEq: ");
      //Serial.print(_description);
      //Serial.print(" | ");
           
      uint8_t asize = sizeof(a);
      const uint8_t asize2 = asize;
      
      //Serial.print("asize: "); Serial.print(asize); Serial.print(" | ");

      // Current a-value to _currmsg
      memset(this->_currmsg,0x00,8);
      memcpy(this->_currmsg,&a,asize2);

      while(asize-- > 0 && this->_currmsg[asize] == this->_lastmsg[asize]);
      Serial.print(" asize: "); Serial.print(asize); Serial.print(" | ");
      // WARNING .. ASIZE = 255 !!!! Meaning both bytes are equal
      
      // Current -> Last
      memset(this->_lastmsg,0x00,8);
      memcpy(this->_lastmsg,&a,asize2);
      
      this->_skip = (asize == 255);
      
      return asize != 0;
    }

@tekka
I just realized that this might affect all request-response operations and a solution might be difficult to find without affecting all users that don't use this particular setup.

It would be ideal if an potential fix could be made so it would only affect the esp8266_mqtt code .. but again .. this might have further implications.

@mfalkvidd

I might have been wrong regarding the timing.

My latest test indicates gateway sends pong at:

573.8

Node starts listeing at

572.8

Still there is not too much time ...

To be extra sure I popped an delay on the gateway side:

	Serial.println(message.type == I_PONG ? "I_PONG" : "OTHER");
	delay(2);
	//Serial.println("")
	bool ok = transportSendWrite(route, message);

Now my node is working again .. I would say the whole issue is an race condition resulting from the great difference in speed.

I found a workaround that is acceptable (for me at least):

In MyTransport.cpp I added an delay(2).
I_PING messages should not be too common to have an impact on battery life and the node now has enough time to switch to receiving mode.

				// general
				if (type == I_PING) {
					delay(2);
					//Serial.print("WE GOT SOME PING?!");
					//Serial.println(sender);
					debug(PSTR("TSP:MSG:PINGED (ID=%d, hops=%d)\n"), sender, _msg.getByte());
					transportRouteMessage(build(_msgTmp, _nc.nodeId, sender, NODE_SENSOR_ID, C_INTERNAL, I_PONG, false).set((uint8_t)0x01));
					return; // no further processing required
				}

https://github.com/mysensors/MySensors/issues/578

@mfalkvidd

It is indded working with 115200 .. at least my terminal is set at this rate and the node too. It even pumped it up to not waste too much time in the serial routines.

I used this sketch:

void setup() {
  Serial.begin(57600);
  pinMode(A4,OUTPUT);
  Serial.println(OSCCAL);
}

// Use hterm to repeatatly send the same message unti you cacn read it
void loop() {
  static uint8_t val = 140;
  OSCCAL=val;
  //Serial.println();
  Serial.print("Osccal= ");  
  Serial.println(OSCCAL,DEC);

  delay(500);
  //digitalWrite(A4,HIGH);
  //delay(1);
  //digitalWrite(A4,LOW);
  //delay(100);
  while(Serial.available())
    Serial.write(Serial.read());
  val++;
  if(val > 200)
    val = 140;
}

It just tries out various settings for OSCCAL .. thus ramping the atmega328 up and speed. There are some settings where I can receive clear messages like in the range from 140 to 160 .. so ist just set OSCCAL to 150.

This might be specific for my current serial-usb converter but for now its fine.

@mfalkvidd

Look at my latest edit of the previous message.

Yep .. for my other 5 nodes (I only assembled 1) I think i will stick with 8mhz .. but it was a nice experiment Thanks for the information with 2,34V. I think this might be enough for now.

PS: I am using http://www.der-hammer.info/terminal/ which is nice as it gives you timestamps on mouse over.
PPS: In addition to the 80mhz of the esp8266 the SPI clock might be much higher too. nrf24 can work with up to 10mhz and my 1mhz node can drive the SPI with at most 500khz (with SPI_DIV_2)

I just confirmed that the ESP8266 is running with 2MHZ spi speed .. so even receiving and sending is potential 4times faster .. not taking into account the 250kbps air data rate .. but it should still give a little lead at reading and writing registers.

@mfalkvidd

I only recently got into the jboard and thought abou trying out 1mhz as described here:

https://forum.mysensors.org/topic/3018/tutorial-how-to-burn-1mhz-8mhz-bootloader-using-arduino-ide-1-6-5-r5/64

I plan to use the jboard with 2x AA so 3,0Volt and the only valid option is 1mhz.

I can only guess that an esp8266 as an gateway in combination with 1mhz nodes is "special".

Now I will check the esp8266 gateway code to look if there are some assumptions on delays etc.

EDIT: For now I can see that the gatway is receiving the PING message .. and that the node is waiting.

		transportRouteMessage(build(_msgTmp, _nc.nodeId, targetId, NODE_SENSOR_ID, C_INTERNAL, I_PING, false).set((uint8_t)0x01));
		// Wait for ping reply or timeout
		//Serial.print("WAITING");
		transportWait(2000, C_INTERNAL, I_PONG);

EDIT2: And that the gateway want's to send out the I_PONG

my debug code got this

WE GOT SOME PING?!11<\r><\n>
We got an message for11 type: I_PONG<\r><\n>
We got an message for11 type: OTHER<\r><\n>

So .. let me try to state the timing:

Node sends I_PING message to Gateway .. at 21:42:52,314
Gateway receives I_PING at 21:42:52,281

waiiiiittt .. the node is still debugging on the serial as the gateway already got the message like 25ms ago? This might be an artifact of my hterm serial console but lets assume it is right.

gateway send I_PONG at 21:42:52,284

So the gateway takes 3ms to process the message including serial overhead .. nice timing

the node reports TSP:CHKUPL:FAIL (hops=255)<\n> at 21:42:54,404

assuming transportWait(2000, C_INTERNAL, I_PONG); takes 2000ms then the node began listeing at

21:42:52,404

whereas the gateway responded at:

21:42:52,281 .. so there seems a whopping 120ms delay caused by some serial output or just the slow 1mhz of the node ..

The gateway already responded while the node didn't even move to the "LISTEN" code ..

This is just a "rough guess" as the timings are only measured using my terminal program but I think this might narrow down my issue

I used this little hack to change the prescaler at runtime to get 8mhz back

http://playground.arduino.cc/Code/Prescaler

#define MY_NODE_ID 11
#define MY_BAUD_RATE 9600

// Enable debug prints to serial monitor
#define MY_DEBUG

// Enable and select radio type attached
#define MY_RADIO_NRF24
//#define MY_RADIO_RFM69
#include <SPI.h>
#include <MySensors.h>


void before()
{
  Serial.begin(MY_BAUD_RATE);
  //OSCCAL=150;
  Serial.println(getClockPrescaler());
  setClockPrescaler(0);
}

void presentation()
{ 
  sendSketchInfo("Test", "Test");
}

void setup()
{

}

void loop()
{
  wait(100);
}

voilla .. the delays are way off but ..

TSM:FPAR<\n>
TSP:MSG:SEND 11-11-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:<\n>
TSM:FPAR<\n>
TSP:MSG:SEND 11-11-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:<\n>
TSP:MSG:READ 0-0-11 s=255,c=3,t=8,pt=1,l=1,sg=0:0<\n>
TSP:MSG:FPAR RES (ID=0, dist=0)<\n>
TSP:MSG:PAR OK (ID=0, dist=1)<\n>
TSM:FPAR:OK<\n>
TSM:ID<\n>
TSM:CHKID:OK (ID=11)<\n>
TSM:UPL<\n>
TSP:PING:SEND (dest=0)<\n>
TSP:MSG:SEND 11-11-0-0 s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=ok:1<\n>
TSP:MSG:READ 0-0-11 s=255,c=3,t=8,pt=1,l=1,sg=0:0<\n>
TSP:MSG:FPAR RES (ID=0, dist=0)<\n>
TSP:MSG:READ 0-0-11 s=255,c=3,t=25,pt=1,l=1,sg=0:1<\n>
TSP:MSG:PONG RECV (hops=1)<\n>
TSP:MSG:READ 0-0-11 s=255,c=3,t=25,pt=1,l=1,sg=0:1<\n>
TSP:MSG:READ 0-0-11 s=255,c=3,t=25,pt=1,l=1,sg=0:1<\n>
TSP:CHKUPL:OK<\n>
TSM:UPL:OK<\n>
TSM:READY<\n>
TSP:MSG:SEND 11-11-0-0 s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=ok:0100<\n>
TSP:MSG:SEND 11-11-0-0 s=255,c=0,t=17,pt=0,l=5,sg=0,ft=0,st=ok:2.0.0<\n>
TSP:MSG:SEND 11-11-0-0 s=255,c=3,t=6,pt=1,l=1,sg=0,ft=0,st=ok:0<\n>
TSP:MSG:READ 0-0-11 s=255,c=3,t=15,pt=6,l=2,sg=0:0100<\n>
TSP:MSG:SEND 11-11-0-0 s=255,c=3,t=11,pt=0,l=4,sg=0,ft=0,st=ok:Test<\n>
TSP:MSG:SEND 11-11-0-0 s=255,c=3,t=12,pt=0,l=4,sg=0,ft=0,st=ok:Test<\n>
Request registration...<\n>
TSP:MSG:SEND 11-11-0-0 s=255,c=3,t=26,pt=1,l=1,sg=0,ft=0,st=ok:2<\n>
TSP:MSG:READ 0-0-11 s=255,c=3,t=27,pt=1,l=1,sg=0:1<\n>
Node registration=1<\n>
Init complete, id=11, parent=0, distance=1, registration=1<\n>

So my educated guss is .. that 1mhz is too slow .. what a pity ;-(

@mfalkvidd

Looking at the serial console I can just see this code:

TSP:PING:SEND (dest=0)<\n>
TSP:MSG:SEND 11-11-0-0 s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=ok:1<\n>
TSP:CHKUPL:FAIL (hops=255)<\n>
!TSM:UPL:FAIL<\n>

If there is no working uplink there is no need for presentation and sketchinfo
Just saying that I don't even come to the point where I could send some actual data.

If I enable debug output on the gateway I get further:

TSM:UPL<\n>
TSP:PING:SEND (dest=0)<\n>
TSP:MSG:SEND 11-11-0-0 s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=ok:1<\n>
TSP:MSG:READ 0-0-11 s=255,c=3,t=25,pt=1,l=1,sg=0:1<\n>
TSP:MSG:PONG RECV (hops=1)<\n>
TSP:CHKUPL:OK<\n>
TSM:UPL:OK<\n>
TSM:READY<\n>
TSP:MSG:SEND 11-11-0-0 s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=ok:0100<\n>
TSP:MSG:SEND 11-11-0-0 s=255,c=0,t=17,pt=0,l=5,sg=0,ft=0,st=ok:2.0.0<\n>
TSP:MSG:SEND 11-11-0-0 s=255,c=3,t=6,pt=1,l=1,sg=0,ft=0,st=ok:0<\n>
TSP:MSG:READ 0-0-11 s=255,c=3,t=15,pt=6,l=2,sg=0:0100<\n>
TSP:MSG:READ 0-0-11 s=255,c=3,t=6,pt=0,l=6,sg=0:Metric<\n>
TSP:MSG:ACK msg<\n>
TSP:MSG:SEND 11-11-0-0 s=255,c=3,t=6,pt=0,l=6,sg=0,ft=0,st=ok:Metric<\n>
TSP:MSG:SEND 11-11-0-0 s=255,c=3,t=11,pt=0,l=4,sg=0,ft=0,st=ok:Test<\n>
TSP:MSG:SEND 11-11-0-0 s=255,c=3,t=12,pt=0,l=4,sg=0,ft=0,st=ok:Test<\n>
Request registration...<\n>
TSP:MSG:SEND 11-11-0-0 s=255,c=3,t=26,pt=1,l=1,sg=0,ft=0,st=ok:2<\n>
TSP:MSG:READ 0-0-11 s=255,c=3,t=27,pt=1,l=1,sg=0:1<\n>
Node registration=1<\n>
TSP:MSG:READ 0-0-11 s=255,c=3,t=6,pt=0,l=6,sg=0:Metric<\n>
TSP:MSG:SEND 11-11-0-0 s=255,c=3,t=26,pt=1,l=1,sg=0,ft=0,st=ok:2<\n>
TSP:MSG:READ 0-0-11 s=255,c=3,t=27,pt=1,l=1,sg=0:1<\n>
Node registration=1<\n>
Init complete, id=11, parent=0, distance=1, registration=1<\n>

But enabling debug output on the gateway slows things down .. my only suggestion is that my 1mhz node is too "slow" for my 80mh gateway .. this is just a wild guess.

My other 8mhz nodes are working fine (complete stuff with presentation, publishing data etc. to mycontroller)

Hello,

I got realy huge problems getting my 1mhz
https://forum.mysensors.org/topic/3018/tutorial-how-to-burn-1mhz-8mhz-bootloader-using-arduino-ide-1-6-5-r5/64

To narrow don the issue I used a minimal sketch for testing:

#define MY_NODE_ID 11
#define MY_BAUD_RATE 115200

// Enable debug prints to serial monitor
#define MY_DEBUG

// Enable and select radio type attached
#define MY_RADIO_NRF24
//#define MY_RADIO_RFM69
#include <SPI.h>
#include <MySensors.h>


void before()
{
  Serial.begin(MY_BAUD_RATE);
  OSCCAL=150;
}

void presentation()
{ 

}

void setup()
{

}

void loop()
{
  wait(100);
}

To sum this up .. if I enabled debugging on the gateway everything is working .. if I disable debugging on the gateway .. nada .. my 1mhz node is not connecting.

I ran into an rather strange problem.

Mygateway is using esp8266_mqtt_client @ 80Mhz and my node is using the 1mhz bootloader.

If I enable debug logging on the gateway everything is working fine.

Upon disabling debug logging on the gateway and enabling debug lobbing on the node I get this:

TSP:PING:SEND (dest=0)<\n>
TSP:MSG:SEND 11-11-0-0 s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=ok:1<\n>
TSP:CHKUPL:FAIL (hops=255)<\n>
!TSM:UPL:FAIL<\n>

Note that I don't use hardware ack. My assumption is that it takes too long to switch from send mode on the node to receive mode and that the gateway is responding too "fast" for the 1mhz node. Could this be possible?

I even tried out 57600baut serial data rate on the node thanks to this "calibration" sketch for the internal oscillator.

void setup() {
  Serial.begin(57600);
  pinMode(A4,OUTPUT);
  Serial.println(OSCCAL);
}

// Use hterm to repeatatly send the same message unti you cacn read it
void loop() {
  static uint8_t val = 140;
  OSCCAL=val;
  //Serial.println();
  Serial.print("Osccal= ");  
  Serial.println(OSCCAL,DEC);

  delay(500);
  //digitalWrite(A4,HIGH);
  //delay(1);
  //digitalWrite(A4,LOW);
  //delay(100);
  while(Serial.available())
    Serial.write(Serial.read());
  val++;
  if(val > 200)
    val = 140;
}

Just add this

void before()
{
  Serial.begin(MY_BAUD_RATE);
  OSCCAL=150;
}

with 150 is the middle of the OSCCAL values where the serial calibration sketch is working. (its working from osccal 140 to osccal 160)

Recently I read a lot about the 0ms, 4.1ms, 65ms start-up time of the low fuses.

I thought adding a small example to prove that the 65ms start-up time is apparently only important during initial powerup.

Used library: https://github.com/rocketscream/Low-Power

Testcode:

#include <LowPower.h>

// the setup function runs once when you press reset or power the board
void setup() {
  // initialize digital pin 13 as an output.
  pinMode(13, OUTPUT);
  Serial.begin(19200);
}

// the loop function runs over and over again forever
void loop() {

  LowPower.powerDown(SLEEP_15Ms, ADC_OFF, BOD_OFF);  
  Serial.write(".");
  Serial.flush();
}

First dot:

Second dot:

= 15ms (sleep) + 2ms (serial communication)
~17ms including overhead for sending serial command

I will try out your bootloader and I can only say that it looks promising

@jkandasa said:

It is necessary in some cases,

• Smart-sleep recently added, before when node wake-up get some date(adjust sleep duration) from controller with request

Yep .. but this would be even more useful if one node could query other nodes data and receive the resonse from the controller (if the other node is sleeping).

Again .. my proposal is to differentiate between:

• Request data from controller (for any other node, including gateway) ( = history query of most recent update the controller knows about)
• Request data from destination node ( = live query )

Edit: I just discovered resource groups on mycontroller .. think this will help out a lot with my planned workaround

Edit2: I could not help myself and request an improvement: https://github.com/mysensors/MySensors/issues/574

@jkandasa

I just never thought that requesting your own configuration from the controller would be needed, exactly as there is saveState and loadState so requesting from controller would be unnecessary.

Okay, thanks for this very good explanation.

@HEK: Would it be possible to adjust the current documentation of mysensor 2.0 request feature to include jkandasa's explanation? If it confuses me I think it might confuse other people as well.

Requesting its own configuration from the controller is a usecase I never thought about.

I thought saveState and loadState should be used to store this data on the node itself.

WORKAROUND #3

To mitigate the issue I think I will save the V_ARMED state on the nodes. In addition to that my nodes will query their own V_ARMED status from the controler. Even if the change of status from CONTROLLER->NODE was not received by the node the node will eventually update to the correct status.

Still somehow sad that there is currently no way for a node to request data from other nodes if they are offline. This could be addressed by changing the request feature:

@HEK: Do you think this is something other users might want as well? If so I would gladly open an issue as featurerequest on github.

• Request data from controller
• Request data from destination node

This would make clear what the request function is for and what the expected result would be.

Okay .. I tried the following:

void loop()
{
  Serial.println(".");
  request(0,V_LIGHT_LEVEL,10);
  wait(50);
  sleep(5000);
}

But I get no response as node 10 is 99% of the time in sleep mode.

This creates a funny situation .. if a node wants to request the latest value of another node .. the other node has to process the request and responde accordingly. This will not working if the other node is sleeping.

If the same nodes requests data from the gateway which is online .. the gateway does not process the message and querys the controller to supply the data .. which it does not have.

Sofar that I understand the request feature it is utterly useless. Either all responses should come from the controller or all responses should come from the designated destination of the message. In the current design it is mixed and is working different for nodes and gateways as destination.

MySensor 1.5


MySensor 2.0


From this reading the controller should never respond to request messages, the destination node had to handle the responde itself. Correct me if I am wrong but this is how it is written in the mysensor documentation.

Okay .. I tried the following:

void loop()
{
  Serial.println(".");
  request(0,V_LIGHT_LEVEL,10);
  wait(50);
  sleep(5000);
}

But I get no response as node 10 is 99% of the time in sleep mode.

This creates a funny situation .. if a node wants to request the latest value of another node .. the other node has to process the request and responde accordingly. This will not working if the other node is sleeping.

If the same nodes requests data from the gateway which is online .. the gateway does not process the message and querys the controller to supply the data .. which it does not have.

Sofar that I understand the request feature it is utterly useless. Either all responses should come from the controller or all responses should come from the designated destination of the message. In the current design it is mixed and is working different for nodes and gateways as destination.

https://github.com/mycontroller-org/mycontroller/issues/264

I think i narrowed down the issue .. the wrong value is returned from mycontroller.org upon receiving the request.

Still the documentation on mysensor should clearly state who will respond the the request message .. the controller or the actual sensor.

@TheoL Thanks for your very quick reply

First and foremost the gateway is a node like any node (from my understanding). It just happended to have the gateway feature enabled:

#define MY_GATEWAY_MQTT_CLIENT
#define MY_GATEWAY_ESP8266

I understand the issue that it is (for me at least) not clear who will responst to the REQUEST function? If I request a variable from any normal node I have to handle the conde in the receive function (I do this on the gateway) .. but as it is a gateway it magically forwards the message to the controller.

In my case the requestions node receives an response .. always payload "1" .. so I am not sure if the controller is not doing its job (mycontroller). I will open an issue there too.

The documentation states:

https://www.mysensors.org/download/sensor_api_20#requesting-data

Requests a variable value from gateway or some other sensor in the radio network.

If the controller should handle the request there should be written:

Requests a variable value from THE CONTROLLER or some other sensor in the radio network.

To differentiate between different messages (for example if the message is a normal "sensor value") which should be send to the controller should be determined by evaluating C_REQ

Having a look at send and request there seems to be a difference:

void request(uint8_t childSensorId, uint8_t variableType, uint8_t destination) {
	_sendRoute(build(_msgTmp, _nc.nodeId, destination, childSensorId, **C_REQ**, variableType, false).set(""));
}

bool send(MyMessage &message, bool enableAck) {
	message.sender = _nc.nodeId;
	**mSetCommand(message, C_SET);**
	mSetRequestAck(message, enableAck);

	#if defined(MY_REGISTRATION_FEATURE) && !defined(MY_GATEWAY_FEATURE)
		if (_nodeRegistered) {	
			return _sendRoute(message);
		}
		else {
			debug(PSTR("NODE:!REG\n"));
			return false;
		}
	#else
		return _sendRoute(message);
	#endif
	}

But from my quick look this is not handled anywhere in the sourcecode

In my current setup I use an ESP8266 as a mqtt gateway.

To maintain a global variable across all nodes I use a V_ARMED on the gateway. mycontroller is able to change the armed variable.

void receive(const MyMessage &message) {
  // We only expect one type of message from controller. But we better check anyway.
  if(message.type == V_ARMED && message.sender != 0)
  {
      Serial.print("Node "); Serial.print(message.sender); Serial.print(" requested armed status");
      Serial.print("Commandtype: "); Serial.print(message.getCommand());
      Serial.println();
      
      MyMessage msg(0,V_ARMED);
      msg.setDestination(message.sender);
      msg.set(armed);
      send(msg);
  }
  else if (message.type==V_ARMED && message.sender == 0) {
     Serial.print("Node "); Serial.print(message.sender); Serial.print(" set armed status");
     Serial.print("Commandtype: "); Serial.print(message.getCommand());
     Serial.println();
     // Change relay state
     if(message.getBool() == true)
     {
        armed = true;
        saveState(V_ARMED, true);
     }
     else
     {
        armed = false;
        saveState(V_ARMED, false);
     }
   }
   else
   {
     
   }
   
   // Write some debug info
   Serial.print("Incoming change for sensor:");
   Serial.print(message.sensor);
   Serial.print(", New status: ");
   Serial.println(message.getBool());
}

however .. running

      // Request armed status from gateway (default)
      request(0,V_ARMED,0);

from my node which I would expect to request V_ARMED from the gatway results in no call of the receive function. Not even the general print statement at the end of the receive function of the gatway is called. Am I missing something?

But one thing is disturbing me

The requestions node gets an RESPONES .. form .. i dont know where ?!

-------------Message Information:-------------<\r><\n>
last:               0<\r><\n>
sender:             0<\r><\n>
destination:       20<\r><\n>
command:     set (1)<\r><\n>
isAck:          false<\r><\n>
type:              15<\r><\n>
sensor:             0<\r><\n>
payload:     1<\r><\n>
----------------------------------------------<\r><\n>

I can only say, that it is not from my gateways .. as there is no output from the receive function.

Upon further notification I noticed this on mycontroller:

This happend after I changed

      // Request armed status from gateway (default)
      request(0,V_ARMED,0);

to

      // Request armed status from gateway (default)
      request(15,V_ARMED,0);

Which leads me to the believe that the function request is actually broken on mqtt_gateway as the message is interpreted the same as any other message and thus relayed to the controller.

enabling debug on the gateway:

0;255;3;0;9;TSP:MSG:SEND 0-0-20-20 s=0,c=1,t=25,pt=3,l=2,sg=0,ft=0,st=ok:0<\n>
0;255;3;0;9;Sending message on topic: mygateway-out/20/0/1/0/25<\n>
0;255;3;0;9;Sending message on topic: mygateway-out/0/0/1/0/15<\n>

Yep ..it is being published .. but why? It is only a request message!!!

Throwing a quicksearch on the mysensor folder results in ...

Wait .. C_REQ is set but there is no code to actually handle it? ANYWHERE?

I opend an issue on github:

https://github.com/mysensors/MySensors/issues/573

I think once in a while there was an article on hackaday:

http://hackaday.com/?s=sell

You probably don't have to reinvent the wheel so why not try to contact some1 who is selling her/his project in small scales?

• contact sparkfun and ask if they know how to start
• http://www.digitalsmarties.net/products/jeenode (maybe ask these guys?)

It is just a wild guess but I would hope people out there to be friendly and give you a push in the right direction

I wish you much luck and success!!

PS: USB ID for the bootloader (5000$) .. why do you want an usb device? If you are just starting why not make a serial connector and sell your product with a already certified USB-Serial connector?

To get the fastest results I would try to disconnect everything from your circuit .. hook up the Multimeter to measure current in lets say 200mA range (if available) and try the deep sleep example from https://github.com/rocketscream/Low-Power

If the pro mini is in deep sleep mode you can switch from 200mA to 2mA or even 200µA range if available. (just don't let the pro mini wake up while you have the range set very low)

Lower measure range = higher burden voltage = potential less power for your µC .. maybe even to the point it will go into brown out or start to behave strange

Putting a multimeter in series will most likeley only cause a voltage drop of up to 200mV (just a rough number). If your circuit draws very little current even routing this current trough the resistor (which is causing the voltage drop) would not result in additional consumption.

Lets look at your switches .. if you are using a setup like this:

http://www.starting-point-systems.com/images/pullup_example.gif

http://www.microchip.com/forums/m341654.aspx states that there should be zero current consumption while the button is not pressed. Are u using this button setup? If not can u provide a drawing?

I don't think that the multimeter is to blame. You reported a very weak batterylife even when you are not measuring the current I guess.

He thinks maybe the fact i am measuring it is causing the extra current... (sounds like quantum entanglement stuff there, "It changed cause you measured it!!")

https://en.wikipedia.org/wiki/Multimeter#Burden_voltage
http://alternatezone.com/electronics/ucurrent/uCurrentArticle.pdf

Long story short .. I would not suspect the burden Voltage to be the problem .. I can measure in the 200µA range with my cheapish Multimeter when the Atmega328p is in deep sleep mode .. so something must be drawing current in your setup.

I would only imagine that the VoltageRegulator might be the culprit.

As you said you use a "3v battery" so there is no need for the VoltageRegulator at all. Where do you apply the power? RAW or VCC? To power your Arduino with higher voltages you connect them to RAW which leads to the regulator.

On most of my projects I use 2x AA Battery which are connected directly to VCC .. even with the VoltageRegulator intact I am at 66% for the last 7 days .. not loosing a single %.

PS: Sry .. I missed that you have already removed the voltage regulator + the led.
The library states to use RISING, FALLING, CHANGE as the interrupt mode but you use LOW .. I don't know to which of the 3 this mapps.

But my guess is you are using FALLING .. thus waking your node up if you connect pin 2 or 3 to ground .. which means you have some kind of pull up don't you?

Do you have anything connected to the Arduino ProMini? If so maybe try an empty sketch and remove all connected peripherals. Maybe even you can find some inspiration on this link: http://electronics.stackexchange.com/questions/49182/how-can-i-get-my-atmega328-to-run-for-a-year-on-batteries

Another really good test on the powerdown current is here:

http://www.rocketscream.com/blog/2011/07/04/lightweight-low-power-arduino-library/

with this library (not compatible with mysensor so dont't use at the same time)

https://github.com/rocketscream/Low-Power