Problems getting sensorID

[hek]

The gateway does not hand out any ids. It's done by the controller behind it.

[klim]

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.

[hek]

@klim

Thanks, this is wrong and will be updated tonight.

[klim]

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?

[hek]

@klim

So far the gateway has had zero "intelligence" and is stateless (except for some routing information).
Pushing the id hand out to gateway would be possible but that means you would have less control and supervision over it from the controller side. Which is kinda bad. E.g. What happens if you "remove" a sensor on the controller side? Should this free up the radio-id as well?
But I guess we all have different views on where to keep the "intelligence". There is no right or wrong here. :)

[klim]

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.

[daulagari]

To manage the network is a gateway part

Within the forum there are people who think the gateway should be light and therefore as @hek wrote zero "intelligence" stateless.

I can follow that, it is nice to have an Arduino Nano run as low layer radio interface to the MySensor network and that meas limited space/functionality.

But yes, I also like to see also some more functionality move out of the controller towards (but not necessary in) the gateway. See also the Another way of organizing variables discussion.

[klim]

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.

[Yveaux]

@klim Sorry to hear it cost you such much time (again) to get things running, but I'm glad you figured it out eventually!
The serial API documentation (http://mysensors.org/build/serial_api) mentions the command string should be terminated by a '\n' character. The actual place where this character is being processed depends on the communication direction of the serial command: from gateway to serial it is added by the MySensors library code (MyGateway.cpp) and the other way around it is parsed in the serial gateway sketch (SerialGateway.ino).

If I'm right, your problem starts in the serial gateway sketch, which waits for the '\n' character.
The sketch waits for a '\n' string terminator character (See http://en.wikipedia.org/wiki/Escape_sequences_in_C#Table_of_escape_sequences and especially the notes below).
The compiler expands '\n' to a linefeed character 0x0a and so te sketch will only pass on the serial string received when it is terminated with a 0x0a byte.

I suspect the terminal program that doesn't lead to a working serial command (which one did you use btw?) does not send the 0x0a terminating byte when you press enter in the console; probably it only sends a carriage return 0x0d.

I hardly doubt the transmit delay is required for te communication to work. On windows I use TeraTerm with transmit delay configured to a default value of 0 ms.

In TeraTerm the linefeed /carriage return issue is nicly illustrated by a configuration entry:

Every LF (linefeed) entered in the serial console window is transmit as a CR+LF (carriage return + linefeed)

@hek Maybe a short statement could be added somewhere to the docs to prevent such issues in the future...

[klim]

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)

[Yveaux]

@klim If it only works with this configuration, then it must indeed be transmit delay related :)

I google'd a bit and see some more Arduino serial communication issues which seem to be solved by adding a serial delay (e.g. http://electronics.stackexchange.com/questions/28739/arduino-delay-of-1ms-necessary-between-serial-read-and-serial-write)
There also seems to be variation over different Arduino versions.

I use 1.5.7. Which version of the IDE do you use?

[klim]

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?

[marceltrapman]

@Yveaux said:

@klim If it only works with this configuration, then it must indeed be transmit delay related :)

I google'd a bit and see some more Arduino serial communication issues which seem to be solved by adding a serial delay (e.g. http://electronics.stackexchange.com/questions/28739/arduino-delay-of-1ms-necessary-between-serial-read-and-serial-write)
There also seems to be variation over different Arduino versions.

I use 1.5.7. Which version of the IDE do you use?

Hmm, this could explain an issue I am having as well.
Lately I started using 1.5.7 (and 1.5.8 since yesterday). I am not really sure but I fear that I have an issue with two sensors that I can't get to communicate properly. Will try 1.0.6 this week to see what happens...

[klim]

I'm curious for your results.

[marceltrapman]

@klim @Yveaux Well, it could be a coincidence because I also moved to the latest git version but, apart from the fact that there is an issue with setting the id of the sensor, it sure looks like I have (better) communication between the repeater and the sensor now that I uploaded the sketch using 1.0.5. With 1.5.x there was virtually no communication between these two...

[app-z.net]

Try this

// gw.begin();
gw.begin(NULL, 15);

[A Former User]

@klim . well so how did you solve this problem ? Urgently need help with this , I am time bound with my project

[A Former User]

@hek so how do I get the controller to hand out the I'd please?

[A Former User]

@hek how do I go about this ?

[Moshe Livne]

@odark007 It would help if you specify what your problem is, include log and sketch. Repeating yourself will not get you anywhere....