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.

DC 1V 1.5V 3V to 3.3V Step-UP Power Converter Voltage Module STM32 FPGA CPLD DSP

$3.99

Sold out

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.