How does mysensors relate to MQTT?

[NeverDie]

@AWI said:

@NeverDie said:

can someone sum it up concisely in a couple of sentences

I love to take that challenge ;-)

1. Instead of entering a highly sophisticated technical discussion. MySensors is just plain fun. Giving everybody the opportunity to (re)enter a world of mixed hard and soft(firm)ware. A hobby supported by a large network of enthousiasts.
2. My daughter calls it "a nerd forum" which is a philosophy on itself
3. (the technical side) MySensors heart is a communication protocol targeted to exchanging standard Sensor information, In that respect is cannot be compared to MQTT as it is a different (higher) application layer (OSI terms). MQTT is an IoT protocol for exchanging messages in a standard way (i.s.o standard messages)
4. The MySensors protocol can be used on top of MQTT so nothing gets in the way...

So far that makes the most sense out of anything I've read so far. So, is this protocol for exchanging standard Sensor Information clearly documented somewhere, or is it implicit in the code and/or code documentation? The reason I'm asking is that if something is broken in the mysensors code, I need to be confident that I can rapidly understand and fix whatever is wrong myself and not wait for someone else to get around to it (which may be never, if it's not high on their own priority list). That's why to me, simple is good. I've seen too many software systems choke under the weight of their own complexity. Take for example, HomeSeer. There's a lot of stuff in it that just never gets fixed. I don't want to be held prisoner like that again. The only way I can see to avoid that is to keep everything dead simple. Being open source is good, but it doesn't free me if it isn't dead simple.

I like to think of it in terms of the NASA module that landed Armstrong on the moon. The astronauts were smart guys, but they didn't have time to fix something if it were to go wrong. So the engineers made the rocket engine for liftoff from the moon absolutely dead simple. No complex ignition systems or fuel injectors. No electronics or electrical involved. No feedback loops or computer algoirthms. Literally, it was just manually opening a valve, which combined the two rocket propellants, which in turn ignited on contact and caused lift-off. Simple is good.

[AWI]

@NeverDie The Serial protocol is where I started. The "complexity" is needed to make a low power (battery operated), cheap,, and reliable sensor network running. A TCP network is pretty complicated by itself.

[TheoL]

@NeverDie Regardless of trying to argue on your idea of having multiple MQTT gateways. There's a single reason that might raise some problems.

At the moment MySensors has no network ID (like Wifi has). So having multiple MQTT gateways in different locations of your house, might cause multiple MQTT gateways to pick up the same message from one particular Node. This means that the data of that sensors can be received by multiple MQTT gateways. Also, if you use ACK it would mean that each gateway will ACK to that Node causing errors on the gateways that didn't send an ACK as first.

I'm interested in your solution.

Another thing that I would not like to experience is having to reset all the SID settings in each node when the router you get from your ISP is being replaced with a new one. Happened to me once and I had to update a lot of devices. That's why I like MySensors and prefer not to use WiFi for my sensors and nodes.

[NeverDie]

@TheoL said:

@NeverDie Regardless of trying to argue on your idea of having multiple MQTT gateways. There's a single reason that might raise some problems.

At the moment MySensors has no network ID (like Wifi has). So having multiple MQTT gateways in different locations of your house, might cause multiple MQTT gateways to pick up the same message from one particular Node. This means that the data of that sensors can be received by multiple MQTT gateways. Also, if you use ACK it would mean that each gateway will ACK to that Node causing errors on the gateways that didn't send an ACK as first.

I'm interested in your solution.

That could be handled in different ways, but the simplest is to have each MQTT gateway use a different channel, and each node communicates with just one gateway (but each gateway has the potential to talk with however many nodes are assigned to it). Each RFM69 can have about 50 non-overlapping channels. So, you could have up to 50 gateways on different channels. I don't think there's a house big enough that would need more than 50 gateways. For most, one or two or three would be enough.

Regarding the SID settings, I'm not sure I understand what the issue is. I just assign each esp8266 a static IP address of of the form 192.168.x.y using the router setup. Actually, on mine, it happens automatically during the initial node setup, but that may be particular to my router.

[TheoL]

@NeverDie it might be me. But I haven't found a way of letting a node communicate to a dedicated Gateway. Really interested if you find a way of doing that.

[NeverDie]

@TheoL said:

@NeverDie it might be me. But I haven't found a way of letting a node communicate to a dedicated Gateway. Really interested if you find a way of doing that.

You can program an esp8266 just like an arduino now, even using the same Arduino IDE. Except it's faster and has more memory. So, instead of an atmega328p controlling an rfm69 or nrf24, you just have the esp8266 do it. You can even use the same sketch as before. That's the basis for your gateway. Your battery powered nodes still work the old way (i.e. controlled by an atmega328p, because it's more power efficient).

[TheoL]

@NeverDie I understand what you mean. Interesting idea. But I'll stick to the normal radio's. Not that fund of Wifi as my WiFi signal is weak because of neighbors with more powerful routers.

I haven't really looked into the ESP. But you might know the answer. Can you install a TLS certificate on it?

[NeverDie]

@TheoL said:

@NeverDie I understand what you mean. Interesting idea. But I'll stick to the normal radio's. Not that fund of Wifi as my WiFi signal is weak because of neighbors with more powerful routers.

I haven't really looked into the ESP. But you might know the answer. Can you install a TLS certificate on it?

You just need a better wifi router. :-) Get a multi-band one with 4x4 MIMO.

I haven't looked into TLS.

[NeverDie]

Here's an example of an esp8266 that's controlling an RFM69 with a dipole antenna. The footprint is barely larger than a US$ 25 cent piece.

[Anticimex]

Exposing all of your sensors and actuators to WiFi is a bad idea from a security point of view. But all is relative.

[NeverDie]

If security is a dominant concern, you could build everything using LoRa, which is inherently more secure.

Anyhow, I use wi-fi on my laptop, and I don't lose sleep over it. Should I? I mean one could always use SSH tunneling if you were extremely concerned. Wouldn't that be good enough?

[Anticimex]

@NeverDie your laptop is not moving the metal part in your door lock (in case you have remote control of your door lock). But more importantly, I would not like to have any yokel with a laptop drive by and be able to interfere with my nodes. And as I understand it, LoRa heavily throttles communication and I don't see how it is more secure.

[NeverDie]

Well,

1. Lora is spread spectrum, and it can operate below the noise floor, so it's harder to even detect it. LoRa can demodulate signals that are 20dB below the noise floor.
2. Likewise, it's more resistant to jamming.
3. I don't think some yokel will drive by with anything capable of messing with it, because he won't know you have it in the first place.

I have z-wave that I installed way back when, and that's far more hackable by a black hat than any of this stuff. Like you say, it's all relative. For all I know some foreign government could unleash a new type of stuxnet designed to criple esp8266's, no matter what the collateral damage, so I can't say the risk is zero. I just think it's vanishingly small.

[Anticimex]

@NeverDie sounds like mysensors is not your cup of tea then.