Posts made by flyswiftly

Seems the node id would server that tracking need.

I wonder if a 'virtual child' of the sensor might be a solution? Just define a second child of the node that periodically sends the opposite status. It would simply be defined in the sketch on the sensor, not tied to actual hardware. First interval, it sends 'true' or 'open' or 1, next interval it sends 'false' or 'closed' or 0. Since it's programmed to change every interval, looking at the last update of the virtual child will let you know the sensor is functional or not.

I can happily report that the boot issue I had has been resolved. It turns out I have 2 nano based sensors to use that are basically the same hardware. However, one of the nano's uses the ch340 serial port and the other uses the ftdi. The ftdi one is the one I had loaded the gateway sketch on. I reloaded the gateway sketch on the ch340 based nano, and it was able to register correctly on the pi during boot.

I found several references to grounding pin 26 ( test ) of the ftdi chip, but that wasn't an option since I didn't have any of the equipment here.
https://www.raspberrypi.org/forums/viewtopic.php?f=91&t=59420

I also found a good reference about creating a udev rule to generate an alias device name in case the usb number changes after a reboot. This may come in handy for some folks.... http://rolfblijleven.blogspot.nl/2015/02/howto-persistent-device-names-on.html

Horst

I have a partial success. It was very easy to add the serial gateway and configure it under HA. I can now monitor both buildings with MySensors. They have different frequencies and don't interfere with each other.

The one issue I still need to solve appears to be a Hasspian ( Raspian ) issue where the serial GW ( arduino nano based ) won't register properly as a usb device on reboot. I need to physically unplug and replug the arduino for it to show up and be usable. In searching around so far, I've found it may be related to the arduino showing as a usb 1.1 device. I've tried a few things, but need to study up and continue troubleshooting. It's likely not really relevant to this forum anyway.

FWIW, I did try extending the one MySensor's tree using repeater mode in the nodes, but it proved to be unreliable, likely due to the distances and walls in the way.

Thanks again for the help,
Horst

Thanks for the great explanation. I'll have the chance to see how it works next week. I'll report back how it comes together.

I have a situation where I have a home and an outbuilding that I would like to monitor and automate with MySensors and HASS. I've seen it written that the MySensors component of HASS supports multiple gateways. I have HaSSbian on Raspberry Pi running in the home, and I have lan access to the outbuilding. It's possible I could use repeater nodes to cover the entire area, but I would also like to explore the possibility of having an ethernet gateway in the out building and a serial gateway in the home. Both gateways would use the nRF24L01+ radio.

1. Is this configuration possible?
2. Could I use the same frequency on both gateways?
3. How would the node address for the gateways need to be configured?

Thanks,
Horst

@rechin304

What library do you use ? The one from MySensorsArduinoExamples-master.zip ?

Actually, no. It turns out when I looked through my IDE that I am using the prior version of the DHT library. That did also force me to comment out the read sensor line just to make it compile. Maybe the combination of the two changes is what does the trick. I hadn't made those changes together, so I missed the possible significance of this change:

void loop()      
{  
  // Force reading sensor, so it works also after sleep()
//  dht.readSensor(true);

Running a diff on both the library you point out and the one I'm using shows that adding that bool to the readSendor function is the only code difference.

@rechin304 said:

dht.setup(DHT_DATA_PIN);
if (UPDATE_INTERVAL <= dht.getMinimumSamplingPeriod()) {
Serial.println("Warning: UPDATE_INTERVAL is smaller than supported by the sensor!");
}
// Sleep for the time of the minimum sampling period to give the sensor time to power up
// (otherwise, timeout errors might occure for the first reading)
sleep(dht.getMinimumSamplingPeriod());

For what it's worth, I just went through a very long debug session trying to get a simple dht11 based sensor built and working. For reasons I don't even pretend to understand, the one thing I changed that allows it to work is changing the 'sleep' command in this section of the setup function to a 'wait' command.