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.