Posts made by klim

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.

Hi, sorry not available at aliexpress anymore, maybe it was just temporary.
But the SR10 (fqn is SR10LG-G) is available at RS-Components and Alibaba.

Powering the mcu and some peripherals is ok, but do you know the maximum burst time of the NRF24l01 when sending? As all of the chips are limited in current by a few mA, i'm not shure if it will work reliable. I know that big capacitors can fix such issues, but is it sufficient?

Here i found a size example of that chips:
power supply

SR086, SR087 and SR10 you can get at ali too.

SR036/SR037 are discontinued products.
Take a look at supertex (microchip) SR086 (Fixed 3.3V) or SR087 (Fixed 5V) or SR10 instead.

Hi had a similar idea but not had enough time to build. I ended up in the stage of evaluating, but maybe it will help you.
As Kezza told you, the problem is the power supply of that devices.
If the devices aren't battery powered, a cheap solution is to use 16x2 LCD displays. If battery powered is a must you have to use low power displays. You can use ePaper/eInk displays which are quite exensive compared to those cheap 2x16 LCDs. Another interesing display technology is, SHARP memory lcd. These are special LCD with very low power consumption. e.g. the SmartWatch Pebble is using it.
If ePaper/eInk or SHARP memory lcd, all of them are expensive and hard to get in low quantities. So if fixed power supply is possible i'd prefere this option because of costs.

I'm curious for your results.

Hi, interesting thread you have linked above. I use latest stable IDE 1.0.6. By the way, can you prefer using the Beta IDE for mySensors developing?

Hi Yveaux, and thanks for your answer. Because i dream about wireless sensors since years, i don't want to give up to early, even if there are problems and much work to do. I already knows about the '\n' terminator and really took care to send LF (0x0A) in each of my tested programs, but thanks to name it as possible failure cause.
By the way, i've tested your suggested terminal program 'Tera Term', configured it like in your previous post, but also without success.

This is the config which is working in my case:

I'm not sure why my environment needs a 'Transmission delay > 0', but I've an idea, so please tell me your opinion to this. I use the Arduino Pro mini 3.3V Version with just 8Mhz as Gateway and Node, could this be the root cause of my problem?
Slower operating speed = different timing (on time critical operations)

Hi again. Today i spent again 6 full hours by searching for a solution for my new problem regarding nodeIDs.

After i got the information from hek, that a controller is needed to get a nodeID, i build up the hardware at my working place today and sent the nodeID manually by entering 255;255;3;0;4;1. Node accepted the ID sent by the gateway via terminal console input. It was great luck that i used the serial terminal program CuteCom under Linux at work, as it was running from scratch. I took the hardware with me. At home i'm working under windows where i was not able to give the node an ID by sending the same command on the gateways serial console (eeprom was cleared before). I was measuring voltage levels again and checking hardware, replaced hardware, checked wires, compiling, reading forum, etc, it was not working at all. I was very disappointing. Why the hell it is not working anymore, i thought. I was on the way to give it up, then i tried to send the node ID request answer from my girlfriends mac book. I needed to look for arduino serial port drivers and a serial terminal program for mac. A search brought up a few programs and i tried each after another while i was playing with settings of those programs until i had success. The node was receiving an ID from the gateway, at last. Now i had the information what special serial port communication setting must be used to get it working. It is "Transmit Delay" and "Termination String". The good was, that the program running under Mac was available for Windows, it's named "CoolTerm".

I tell you my whole story to save you time and trouble.
Below you can find programs and settings, running on the operating systems i called before.

Linux: CuteCom

Mac: CoolTerm

Windows: CoolTerm

Hope this was useful for you.

Hi, and welcome. If it helps you, i did the same mistake, but in my case the documentation was wrong at the time.

Today i compiled it serveral times with IDE 1.0.5 under windows without a problem. And after some time i got exact the same error message as you. So i decited to use 1.5.7 beta to compile, there are some other ugly compiling messages, but at the end it was successfull for me.

Hi, i fully agree with your statement "We all have different views... / There is no right or wrong here"

**My personal opinion to this: **

• To manage the network is a gateway part
• Fully control of the network from the controller side should be possible too. But the controller sends the network topology changes to the interface of the gateway, not directly to the nodes.

In that case of have all the time a fully working network without a controller, just my point of view.

Thank you for clearing this to me. It was driving me crazy the last few days. I spend lot of hours searching all kinds of failures in my environment, hardware, software, etc.

But back to topic, doesn't make it more sense to let the gateway handle the sensorIDs. In that case, the sensor network itself would be independently (from a controller) and can work from scratch. I know, to get further automation there is a controller needed.
But i think more about layer-abstraction and move basic network operations closer to the network related equipment. What's your opinion to this?

Hi, and thanks for fast reply.

Here you can read something different:
link text

**An excerpt from what i mean in special:
**
Each node is assigned a unique sensorId or address that is used for sending and receiving point-to-point messages. You can assign a static sensorId or let the gateway automatically assign one to the sensor. AUTO-mode configures the sensor to request a sensorId from the gateway and is the default option for all the examples that we provide. The sensor stores the assigned sensorId in its non-volatile memory to ensure the correct sensorId persists across power transitions.

Hi guys, first a big thanks for your great work. I spend lot of hours (~15h) to get your examples running, but without success. So i ask kindly for your help please.

I build up a gateway and a sensor node. All code is untouched example code from git or mysensors.com.
The problem i've, that the node does not get a sensorID from the gateway.
The sensor sends a request to the gateway, the gateway receives the request and that's it.

gateway log:
*0;0;3;0;14;Gateway startup complete.
0;0;3;0;9;read: 255-255-0 s=255,c=3,t=3,pt=0,l=0:
255;255;3;0;3;
0;0;3;0;9;read: 255-255-0 s=255,c=3,t=3,pt=0,l=0:
255;255;3;0;3;
0;0;3;0;9;read: 255-255-0 s=255,c=3,t=3,pt=0,l=0:
255;255;3;0;3;
0;0;3;0;9;read: 255-255-0 s=255,c=3,t=3,pt=0,l=0:
255;255;3;0;3;
0;0;3;0;9;read: 255-255-0 s=255,c=3,t=3,pt=0,l=0:
255;255;3;0;3;
0;0;3;0;9;read: 255-255-0 s=255,c=3,t=3,pt=0,l=0:
255;255;3;0;3;
*

sensor log
eq node id
send: 255-255-0-0 s=255,c=3,t=3,pt=0,l=0,st=ok:
sensor started, id 255
req node id
send: 255-255-0-0 s=255,c=3,t=3,pt=0,l=0,st=ok:
req node id
send: 255-255-0-0 s=255,c=3,t=3,pt=0,l=0,st=ok:
req node id
send: 255-255-0-0 s=255,c=3,t=3,pt=0,l=0,st=ok:
req node id
send: 255-255-0-0 s=255,c=3,t=3,pt=0,l=0,st=ok:
req node id
send: 255-255-0-0 s=255,c=3,t=3,pt=0,l=0,st=ok:
req node id
send: 255-255-0-0 s=255,c=3,t=3,pt=0,l=0,st=ok:

As the eeprom of both was filled up with 0xFF (255), the sensor starts with id 255. As all MySensor code examples are configured to work with AUTO ID, the sensor should get an ID and hold that in the eeprom, but this does not happen in my environment. Am i right until here?

After reading some parts of source code, i've tried manually to write the sensorID to the sensor eeprom and sensor starts with sending out his presentation and sensor data. Gateway was receiving sensor data too.
Maybe the communication is only working in one way: sensor-->gateway, but not in the other way: gateway-->sensor. But why??

A listing what i've already tried:

• hardware:

• gateway:

  • type:
    • serial
    • ethernet
  • arduino:
    • pro mini 5V (m328)
    • pro mini 3.3V (m328)
    • uno (m328)
    • mega 2560

• node:

  • arduino:
    • pro mini 5V (m328)
    • pro mini 3.3V (m328)
    • uno (m328)

• nrf24l01:

  • capacitors:
  • foil 100nF
  • and electrolytic capacitor (1µ - 470µ)
  • power supply
    • arduino powered and external power supply
    • 3.3v stable, yes
  • connection
    • verified 100 times, it must be correct
    • breadboard and flying wires
  • tried 10 different nrf24l01 modules
  • modules looks like this:
    

• software:

• ide

  • 1.0.5-r2 (windows)
  • 1.0.5 (linux)
  • 1.5.7 beta (windows)

• mySensors

  • 1.4 stable
  • 1.4 dev
  • 1.3 stable
  • eeprom clear, yes - many times

I've read a lot of forum posts, but without any answer that fixed my problem.
I have no idea anymore what i can try as next.
So please, i need you help.