Sending to multiple receivers? I don't get that gateway thing...

[MrGlasspoole]

I'm confused about that gateway thing. All the examples are in that way that all the senders talk to one gateway.

Lets say i have one RFM (#1) that collects data to a database and can send commands from a web interface (temperature)...
A second one (#2) is a radiator valve...
And the third one (#3) is just a temperature sensor (just sender)...

The temperature sensor needs to send the temp to #1 (to log the temp into the DB) and to #2 to tell the valve it needs to open ore close.
Then #2 also needs to send the valve status (open/closed) to #1 (into the DB).
#1 also needs to talk to #2 that you can set the desired temperature or to open and close the valve manually.
Also they all need to do ACK among themselves...

All the examples have one gateway that is the receiver?

Another example would be this plug adaptors you can buy everywhere. You have a remote with 3-6 buttons to switch the
different outlets on or off. I can't figure out how to make one RFM with multiple buttons sending to different RFMs if i need
to set one gateway. How do i say: button one = outlet 2 / button two = outlet 3

How does the whole thing work in detail? Every RFM is receiving everything the whole time and in the code you decide if the
received message is for that Moteino and it should do something?

[Felix]

They are all transceivers, they can receive and send.
The gateway is the data aggregator and the gateway application is who decides what to do, listen for events and tell a node to do something. You can always have nodes talk between them independently of the gateway but then you forfeit your control via the gateway which is the whole point of the gateway. It allows you to control every aspect of the node network, remotely.
Watch john's videos.
https://lowpowerlab.com/blog/2016/02/20/johns-gateway-setup-and-new-node-test/
https://lowpowerlab.com/blog/2016/02/01/johns-gateway-deep-dive-2-utility-room-node/
https://lowpowerlab.com/blog/2016/01/04/johns-gateway-deep-dive-1-configuration/

[MrGlasspoole]

I know they can send and receive but i can't figure out how to send from 1 transceiver to 2 receivers...

If i understand you right and from the Videos you do it like most people with there home automation stuff.
I don't like that concepts of gateway/server. I see people using Node-Red and openHAB and i don't
get this single point of failure concept.
I believe things should talk to each other without having servers running between them doing the logic (if this then do that).
I don't want my radiator to be cold or not be able to switch the light because a rPi is broken or an software update messed things up.

If the sensor can send the temperature directly to the valve, then why send it first to a server and then from the server to the valve?
I use MQTT since 3-4 years and can control my TV, Sat-Receiver with JavaScript<>MQTT<>IR from any device that can run a website.
This also works for the HTPC where i use ZoomPlayer (TCP socket).
Websockets can show sensor data live with MQTT in any browser/app.
And sure i can switch lights.
But the point is: everything also works without the MQTT server. That means every light has a physical button
And heating control and all other things should be like that.

I remember there was an report where somebody was trapped in his garage for two days (or something like that) because the
servers of his funky hi-tech automatic home went down

I'm a big fan of MQTT and was searching for MQTT-SN - but there is still nothing out there.

[joelucid]

To some extent the centralization is mandated by the low power nodes which just can't be awake much and rely on someone to capture and cache their state and that of other nodes they might be interested in.

Doesn't need to be the gateway. But someone with more power needs to take care of the lowpower nodes.

[MrGlasspoole]

someone to capture and cache their state

Capture would be an ATmega with RFM69 and WIZnet5500. Cache would be V.I.N.CENT - he is my Hyper-V 2012R2 Core Server running pfSense, FreeSWITCH, Win8.1 and Debian.
The ATmega sends everything (MQTT) to Debian (HiveMQ as Broker) and writes the data into Redis.

and that of other nodes they might be interested in.

What do you mean with that?

Please explain my question:

How does the whole thing work in detail? Every RFM is receiving everything the whole time and in the code you decide if the
received message is for that Moteino and it should do something?

How does a Moteino know if the message is for him (turn on light because on another Moteino a button was pressed) if you have multiple of them listening?
They are sleeping and only the RFM69 is listening. They all wake up the there ATmega and check if the structure in there code matches and do what they should?
If the structure does not match they go back to sleep?
But with 20 temp sensors that would mean they all wake up permanent because everybody is listening and receiving something?
I guess that is not how it works

And how do i send my temperature to two notes at the same time?

[Felix]

I don't like that concepts of gateway/server. I see people using Node-Red and openHAB and i don't
get this single point of failure concept.
I believe things should talk to each other without having servers running between them doing the logic (if this then do that).
I don't want my radiator to be cold or not be able to switch the light because a rPi is broken or an software update messed things up.

Well, it's totally up to you how you want to approach things. Having a central node has advantages but probably won't satisfy all possible scenarios. The fact that most people drive cars on freeways doesn't mean everyone should. There are people that don't get that concept, and they can only drive offroad that's totally fine too.

[syrinxtech]

someone to capture and cache their state

Capture would be an ATmega with RFM69 and WIZnet5500. Cache would be V.I.N.CENT - he is my Hyper-V 2012R2 Core Server running pfSense, FreeSWITCH, Win8.1 and Debian.
The ATmega sends everything (MQTT) to Debian (HiveMQ as Broker) and writes the data into Redis.

and that of other nodes they might be interested in.

What do you mean with that?

Please explain my question:

How does the whole thing work in detail? Every RFM is receiving everything the whole time and in the code you decide if the
received message is for that Moteino and it should do something?

How does a Moteino know if the message is for him (turn on light because on another Moteino a button was pressed) if you have multiple of them listening?
They are sleeping and only the RFM69 is listening. They all wake up the there ATmega and check if the structure in there code matches and do what they should?
If the structure does not match they go back to sleep?
But with 20 temp sensors that would mean they all wake up permanent because everybody is listening and receiving something?
I guess that is not how it works

And how do i send my temperature to two notes at the same time?

The radio knows if the message is intended for it by the node ID, which is part of the packet header.  It's the one-byte field you setup when you initialize the radio.  If you want to send from one node to more than one node, I see two options:

1.  Either send two packets, one addressed to each node.  This obviously takes more time, more battery and more bandwidth.
2.  Turn on "promiscuous mode" and therefore let everyone hear all transmissions.  You will have to do more work to make sure you're listening to the right node but it's doable.

[Felix]

I forgot to mention something. When I designed SwitchMote, I wanted the nodes to talk between them independent of a gateway. So they can turn each other on, and no gateway is ever needed. This would allow someone with no knowledge of how the internals work to configure, synchronize and use them (well after the initial loading of the sketches).
I can think of ways you could link SwitchMotes with MotionMotes to turn on lights directly when motion is detected, without a gateway intervetion. But of course, then you have to turn off the MotionMote or come up with some other way of disabling that then you don't want the light to turn on. Right now this same functionality is available on the gateway software, where you have an event which you can turn on-off from a click of a button. So this is a perfect example where having a gateway makes a lot of sense. Yes its an extra point of failure, but aren't all nodes points of failure?

[WhiteHare]

How much latency does using the gateway introduce?  I'm guessing not much, but I haven't tried it so I don't know for sure.  I do know that with z-wave going node-to-node seems almost instant, whereas going through a z-wave gateway introduces a palpable delay.  Apples and oranges, I know, but it's the basis for the question.

[Felix]

I am sure my RFM69 libs and gateway have less layers than z-wave and the delays are pretty much non-noticeable with my gateway stack.