Hi, i've the same problem with a toggling Inclusion signal in my SerialGateway and mySensors version 1.4.2. I understand that a missing pullup resistor on Pin3 and a none activated internal Pullup is the root cause of this problem. I solved it by modifing the MyGateway.cpp like this:

	// Setup digital in that triggers inclusion mode
	if (pinInclusion >= 0)
	{
		pinMode(pinInclusion, INPUT_PULLUP);
		// Add interrupt for inclusion button to pin
		PCintPort::attachInterrupt(pinInclusion, startInclusionInterrupt, FALLING);
	}

Does this mean this there is an error in 1.4.2?

thanks, i'll give it a try.

I already mentioned direct access eeprom addresses. I don't like it, because of loosing all the benefits of structured eeprom access.

Thanks for reply. This means, my it is not possible do it that way, right?
Any other ideas to generalize eeprom access?

Hi, just wanted to ask about any ideas, not to make a feature request. But in general i think this could be useful for the whole mySensors project.
What i built already:

-Used the EEPROMAnything.h library for structured eeprom access
-Wrote a Payload parser for: command,section,value e.g. write,value1,199
-But then i've a problem to access the struct sections

Here's an excerpt about my solution:

struct store_t {
byte version;
int value1;
unsigned long value2;
char code[5];
} configuration;

The parser separates the Payload into:
-command <-- e.g. write
-section <-- e.g. value1
-value <-- e.g. 199

To read data from the struct i can simply use** configuration.value1** which works fine.
But i want to use the data from the Payload like ** configuration.section** where the section holds the struct section name to access.
The only nasty solution i figured out was, comparing the Payload section with a string.

if (strcmp(payload,"value1") == 0) {
Serial.println(configuration.value1);
} else
if (strcmp(payload,"value2") == 0) {
Serial.println(configuration.value2);
}

How could i do that better?

Thanks a lot for fast replay, meanwhile i'll just use another separator. I'm very curious about the json solution.

Hi, a semicolon in payload trims the payload to the size of the semicolon position.
Is this intentionally or just a side effect of the mysensors serial api format, because the data before payload is also separated by semicolon?

Hi i hope you can help me finding a solution for my requirement. I want eeprom content to be fully manageable via mySensors protocol using payload.
The previous days I've tried a few solutions but I'm unsatisfied with all of them, here are some of my unusable solutions:

• Each eeprom value has it's own function for accessing --> stupid solution e.g. Payload: readValue1
• Direct access eeprom addresses --> hassle solution without structured access, datatype length problem. e.g. Payload: %command%,%address%,%value% --> write,0x10,255

Please note, the above Payload examples aren't real, they are just for better description.

I want a generic solution to manage eeprom values with the use of structured eeprom access, optionally where the node can give information about it's structure (variables and datatypes) to the controller for easier management. Do you have any ideas who to do that, please?

I'm actually working on a mySensor KeyPad node, but currently i'm struggling with a generic solution to read/write eeprom configurations controlled by the gateway. Maybe i'll ask for help in this forum in near future for future.

Regarding the SR10 i've already here a few, but just no time to build up something ;-(
The more i'm curious for your results.

hi, is your work on ota based on internal o external flash?

That's the reason, we must use instruments and methods to give predictions, instead of waiting for real results ;-)

I know about the problems and accuracy for very low current measurements without special instruments. Therefore i want to buy a µCurrent Gold adapter soon, it is a very cost effective way to measure very low currents. This adapter with the combination of a digital oscilloscope with math is what we need here. But at the end as therik already said: the final test is to see how long the battery actually last

Thanks for your info. That was my toughts too, to use an oscilloscope and integrating the current over time, but first i need a good digital oscilloscope to do that.

Thanks a lot for clarifying, i didn't thought about that before. This means the power consumption is not as good as it seems.

@m26872: Why should i measure a dc current in ac mode? I did it anyway, the result was 0.87mA when sleeping. Please enlighten me.

@daulagari:
I'm aware of that it is not the best option to mount them close to each other, but as it is just a prototype nearly everything is allowed :-)
I did a quick test with success on a distance of 5m through a cement-wall of 20cm width.
A capacitor for NRF24l01 is already on board, it's the grey one with a capacity of 4µ7. I know it's just an ordinary aluminium capacitor and not low-ESR, but i had nothing other at home.

@that0n3guy:
Again tested at battery side: 90µA @ 1.5V --> 135µW. Take a look here:

Hi, based on the results of my last measurement the sensor needs 90µA, while sleeping + consumption for transmitting, but this depends on the configuration.
The theoretical battery life just for sleeping (without battery self discharge) should be:
2500mAh/90µA=27777h
27777h/24h=1157d
1157d/365d/3,17a

Hi, at the time i've just tested a few meter, sorry to be not more specific, i've not measured it. Because of the NRF module has a gnd shield on the bottom side and the StepUp too, so they have their gnd sided very close to each other, i hope to not get any signal losses.

Hi, i want to present you my working but not really sexy looking single cell AA battery sensor. It is as it is - under development and was just made to get some experience about power consumption and physical size.
I thought a lot about the type of battery to choose, but at the end i desisted to use an ordinary AA cell. I know about the advantages and disadvantages of different battery chemistry and types, but in the aspect of price/mA the AA battery is still the winner. Self discharge of a few years is acceptable for that type of battery.
Another aspect i followed is, just to use buy-able and assembled modules, as i don't have enough time to build my own arduino board, or battery management (step up), etc. .....

The core of the sensor is the battery itself. The components are mounted around the battery. The sensor can be completely disassembled in a few seconds, as the modules are just connected with pin headers.
The power consumption for sleep is around 90µA, if i can believe my Fluke 175. The power consumption of normal operation and transmit i don't post here, because of two reasons:

1. I was not able to get a good measurement result with a multimeter. I should integrate the consumption over time to get a real result.
2. The lifetime of a sensor is dominated by the sleep consumption, not by the operating consumption (if transmission time is just a few times per hour)

There are still some improvements to do, but ehh, this is just a prototype.

Used components:
-Arduino pro mini 3.3V @ 8Mhz (mcu board)
-NRF24L01 (wireless board)
-3.3V StepUp (0.8V-3.3V from Canton electronic an ebay product link)

Modifications:
-Arduino board: Cut LED
-Arduino board: Cut LDO
-StepUp board: Cut LED

Physical dimensions (without pin headers):
65mm x 22mm x 25mm

Which values the sensor can send?
In general this is just a battery monitor, as i want to get some experience of power consumption, but the pin header is able to work with various types of sensors. I use a simple DS18B20 temperature sensor on the header pins.

Here are some pictures:

Overall view1

Overall view2

Overall view3

Overall view4

Unused space over battery, but i didn't had the correct pin headers at home "mea culpa"

Disassembled view1

Disassembled view2

Assemble view1

Assemble view2

Assemble view3

Assemble view4

Assemble view5

Bottom view (remember - just a prototype)

I hope i could give you some potential ideas for your own project.
Questions, suggestions, feedback, all is welcome.