Gateway/sensor Range Advice

[BulldogLowell]

You cannot move the gateway to the middle floor? That's the nice part of iethernet vs. serial gateway... Just run a wire.

Did you already add repeater capability to your existing sensors?

[Dan S.]

@BulldogLowell Don't think I can move gateway to middle floor--the only internet connections (other than wireless) that I have are in the basement and everything including most of the basement is finished.

Did not add repeater capability to existing sensors. I thought repeater has to be separate from sensors since they can never sleep?

[daulagari]

@Dan-S. What kind of walls/floors do you have?

Here in Holland, concrete is quite standard and concrete contains metal; I see that typically it is not possible to cross two walls/floors reliable with WiFi, so that should also count for MySensors. Range is best if antennas can "see" each other directly (through a door/stairwell).

Yes, a repeater can not sleep and can therefore not really be battery operated.

Can you run a cable from your basement to the middle floor?

[tbowmo]

You can combine sensor and relay into a single node, however, as the radio can't sleep, batteries won't last long. So they need to be powered externaly

if you have nodes that can be used as actuators, then they also need to be on at all time, as they should be able to receive commands from the GW, so they could in theory be made as repeaters as well..

[Dan S.]

My house is wooden frame with plasterboard walls so cross floor/wall commo is OK. My one sensor on the main floor is a light sensor and is not battery powered. But don't you still need it to sleep between light readings? How do you make a combination sensor/repeater? The sketch for the repeater indicates that the repeater has a unique node declaration. that is different from the sensor node declaration

[tbowmo]

@Dan-S. said:

My house is wooden frame with plasterboard walls so cross floor/wall commo is OK. My one sensor on the main floor is a light sensor and is not battery powered. But don't you still need it to sleep between light readings? How do you make a combination sensor/repeater? The sketch for the repeater indicates that the repeater has a unique node declaration. that is different from the sensor node declaration

It's not necessary to sleep between node status messages. You can implement the delays between messages, with millis() instead.

so something like this would work: (will send measurements every 60 seconds)
void loop()
{
gw.process();
if (millis() - lastMeasurement > 60000) {
lastMeasurement = millis();
sendMeasurements();
}

Also have a look at http://mysensors.org/build/sensor_api#sensor-nodes, there are descriptions on how to enable repeater mode, in normal sensor nodes.

Ps. the code above is made purely from memory, and there might be some parts left out, or spelling errors :)

[Dan S.]

@tbowmo Sounds like that would work. Will try it out.

Is it best to use the radio with the separate antenna for the repeater?

[hek]

@Dan-S.

Should work fine with the vanilla version.

[Dan S.]

Revised my light sensor sketch to give it repeater capability. The key is in the millis() function which keeps track of processing time. Did some research and learned that because it is an unsigned long data type it will rollover to zero after 49 days! So unless you write the comparison statement in the if clause a certain way it will fail after 49 days. If you do a search on how do you reset millis() you will learn how to set up the if clause to take care of rollover (you can't easily reset millis and you shouldn't since it will cause major problems for other libraries that use it).

I could not find any description in http://mysensors.org/build/sensor_api#sensor-nodes on how to do this. I do think a sample combined sensor/gateway sketch would be very useful.

I have not tested my revised light sensor/repeater sketch (it does compile). Will report back on results of testing.

[raditv]

Interesting about millis(), is there anyone here running mysensors more than 50 days?

[BulldogLowell]

@Dan-S. said:

unsigned long data type it will rollover to zero after 49 days! So unless you write the comparison statement in the if clause a certain way it will fail after 49 days. If you do a search on how do you reset millis() you will learn how to set up the if clause to take care of rollover (you can't easily reset millis and you shouldn't since it will cause major problems for other libraries that use it).

I could not find any description in http://mysensors.org/build/sensor_api#sensor-nodes on how to do this. I do think a sample combined sensor/gateway sketch would be very useful.

I have not tested my revised light sensor/repeater sketch (it does compile). Will report back on results of testing.

The millis() rollover problem is sort of a red herring. You will never have a problem if you are strictly using unsigned long integer SUBTRACTION like this:

unsigned long lastRunMoment; // the timeStamp you use to constantly check vs the current time (millis() returns an unsigned long timestamp)

unsigned long myInterval = 10000; // the frequency that this timer will execute here... 10 seconds.

void setup()
{
  Serial.begin(115200);
}

void loop()
{
  if (millis() - lastRunMoment > myInterval) // this unsigned subtraction works...
  {
    Serial.println("This works");
    lastRunMoment = millis();
  }
}

/*
// NOT Like This:
void loop()
{
  if (millis() > lastRunMoment + myInterval) // this unsigned addition will not survive the millis() 49day rollover.
  {
    Serial.println("This doesn't work");
    lastRunMoment = millis();
  }
}
*/

you can learn why here

[Dan S.]

@BulldogLowell That's exactly right. You stated it more clearly than I did. It's not a problem if you're careful in how you set up your if test but its does warrant a warning to be careful in that regard to anyone using mills() for timing their sensor reads.