CAN vs MQTT: Best Protocol for a Reliable and Secure Shelved Room System? - Page 1
Forum section: electronics / projects

author: z0ki
author_rank: Newbie
timestamp: December 23, 2024, 10:35:02 am
content: Hi there! I'm planning a communication system within a closed room (variable but should work up to 10x10m) filled with shelves, connecting up to 10–40 nodes distributed over the shelves to a central processing unit, would CAN or MQTT be the better choice? (The system will have to be CE-certified).\Key details and criteria are:1. Environment and Layout:- The room has minimal external interference or noise sources.- The nodes sit in the shelves and need to transmit simple sensor dataonly when a state changes.- To ensure full coverage, the total cable length for CAN could reachup to 80m, given a potential serpentine cable routing cable layout.2. Reliability and Security:- The system must be reliable for transmitting data without loss. When a change occurs it has to be received by the central processing unit in under 1 second, losses would be fatal.- Security against hacking or tampering is crucial.3. Modularity and Scalability:- Nodes must be modular, with connectors allowing easy plugging and unplugging. The cables would run in the floor with sockets for plugging in nodes, if there is a shelve at the respective location. The layout of the shelves and therefore nodes might change sometimes, but not too often (like 1-2 times a year).- The system will be used in rooms of different size from 3x6m to 10x10m. But all rooms should run with the same system.4. My thoughts:- CAN comes with higher hardware and cabling complexity, potentially reducing modularity.- MQTT is more flexible and easier to set up but may require WiFi networking, leading to higher power consumption, increased security concerns, and possibly more expensive CE certification.Given these factors, which protocol would be more suitable for this setup, and what are the trade-offs to consider in terms of implementation complexity, scalability, reliability, and security?

author: fchk
author_rank: Frequent Contributor
timestamp: December 26, 2024, 05:12:40 pm
content: CAN and MQTT are on different protocol levels and not easily comparable."The system must be reliable for transmitting data without loss. When a change occurs it has to be received by the central processing unit in under 1 second, losses would be fatal.": This implies wired communication only. Period.The easiest way is plain Ethernet. Optional with POE for powering, either standard 802.3af or just passive POE 48V on pin 4/5 and 7/8.The smallest and cheapest Ethernet node is a PIC18F67J60. CPU, RAM, Flash, peripherials, Ethernet MAC and Ethernet PHY in one single 64 pin chip. You only need to add 3.3V power, a 25MHz crystal, and some passives. The RJ45 magjack is the most expensive part. A more modern solution would be CH32V307, but availability in general and especially long term availability might be difficult.Protocol: MQTT is TCP. Not good for your application. Use something UDP based or even raw UDP broadcasts. Together with an MAC serial eeprom (25aa02e48t-i/ot) this would be configuration free.

author: Siwastaja
author_rank: Super Contributor
timestamp: December 26, 2024, 06:26:36 pm
content: Arguably, CAN would be even simpler than UDP over Ethernet. Both require some way of packet loss detection, timeout and "fail safely" logic.MQTT is a mess. Won't recommend except if you need to interoperate with something which already is MQTT. Commonly available implementations (such as Paho Embedded) are undocumented, unmaintained and seriously buggy; it's a can of worms, and it's usual none of the "advanced" features (like QoS levels beyond 0) actually work. In this case, MQTT would add nothing of value on top of raw usage of the layers below it, only additional issues.

author: DavidAlfa
author_rank: Super Contributor
timestamp: December 26, 2024, 06:46:41 pm
content: You don't even need can, only differential signaling for best reliability over long distances, attaching a uart or SPI to a diferencial transceiver will do it.The protocol can get really simple, like[ dst src cmd len msg checksum ]which the receiver has to ack returning a message with the original checksum.Cmd byte tells what kind of message is being received (msg, ack, nak, etc).The sender sends the msg and waits for ack, resending the frame if not ack'ed within a reasonable time and giving up after a certain number of unsucessfull attempts.

author: fchk
author_rank: Frequent Contributor
timestamp: December 26, 2024, 07:19:12 pm
content: Quote from: Siwastaja on December 26, 2024, 06:26:36 pmYes, from a hardware standpoint it would. But this requirement"Nodes must be modular, with connectors allowing easy plugging and unplugging. The cables would run in the floor with sockets for plugging in nodes, if there is a shelve at the respective location."strongly suggests a star topology, not a bus topology used in CAN or RS485. TP Ethernet does match this requirement much better. You can plug and unplug nodes without disturbing the bus, and a fault on one port does not affect the others. With managed Ethernet switches you can monitor both the data connection and the power of each node, gaining higher reliability without the need of reinventing the wheel.

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 26, 2024, 10:09:53 pm
content: Yeah, Ethernet is probably the easier and more flexible path here. If you don't want to be stuck with only MCUs directly supporting Ethernet, you can consider using one of the Wiznet chips to add Ethernet interfacing to your nodes. They are not expensive and pretty easy to use.

author: H.O
author_rank: Frequent Contributor
timestamp: December 27, 2024, 07:33:07 am
content: For Ethernet, perhaps the W5500-EBV-PICO module?I don't think you're going to put a PIC18F67J60 with surounding parts on a PCB for less than what it costs.

author: 5U4GB
author_rank: Super Contributor
timestamp: December 27, 2024, 09:26:54 am
content: The OP mentioned "Security against hacking or tampering is crucial" which pretty much rules out anything but something at a higher layer run over Ethernet. OTOH this is also a motherhood-and-apple-pie requirement that can mean almost anything, for example there's no point in running nitrogen-pressurised armoured coax between your devices if they're Arduinos. What lever of hacking or tampering are you expecting?

author: Siwastaja
author_rank: Super Contributor
timestamp: December 27, 2024, 10:11:27 am
content: I missed the tampering requirement. It is so freaking difficult to achieve in a setup like this that my brain mentally ignored it as being unrealistic. If OP is capable of doing that, they would not need to ask whether "MQTT or CAN is better".As a note, tampering means someone has physical access; things like ATMs and door locks have tamper protection systems.

author: 5U4GB
author_rank: Super Contributor
timestamp: December 27, 2024, 10:17:58 am
content: As a proposed sample of possible threat models, might I suggest Figure 1 at the bottom of page 9 ofthis?

author: peter-h
author_rank: Super Contributor
timestamp: December 27, 2024, 01:20:52 pm
content: Budget is not mentioned and if not a problem, nothing beats ETH with POE for sheer convenience.MQTT is all the rage and 53% of the world is trying to find ways of making money out of it, starting with AWS flogging server services for IoTPointless for this.CAN is rather a physical layer and most users (which is mostly automative nowadays, after all the rage of decades ago died down, plus oddball apps like Garmin avionics interconnections) are running proprietary protocols over it. It is, crudely speaking, basically 2-wire RS485, no galvanic isolation, and thus no better than just running 2w 485 with your own master/slave protocolRe security, will there be physical (access control) security? If not, there will be zero security! What will the enemy do with a wired system? Not a lot he can do, apart from Van Eck kind of stuff.

author: Siwastaja
author_rank: Super Contributor
timestamp: December 27, 2024, 05:06:14 pm
content: Quote from: peter-h on December 27, 2024, 01:20:52 pmLOL. But not really; reading some forums easily gives you this impression but it seems in reality no one uses MQTT, the protocol is nearly abandoned and so are the implementations. Plus side is, it's a really simple protocol, the whole thing is nearly trivial. It is something that given the exact same requirements, you would create from scratch over a weekend. Which is good. And the official specification is good and well written. Then again, if your requirements are different, it's only going to be an extra layer of unsuitability which you then work around by adding another extra layer on top of it - which could have been sitting directly on TCP instead. I mean, theoretically MQTT abstract TCP sockets dying and reconnecting, but since this feature is broken in real implementations so that you can't use it, all that is left that MQTT gives you is topic names and subscriptions on them with a simple wildcard support.And because MQTT is forgotten and frozen, you are going to need to fork the implementations and fix bugs in them. Which is not impossible because the thing is so simple, but this raises a question, what for?Really, the only solid answer to "why MQTT" is: because some existing system you need to interface with uses MQTT. Or, you have too much free time and need a hobby, so you get into Home Assistant. That is what you use MQTT for, basically the only existing use case.

author: peter-h
author_rank: Super Contributor
timestamp: December 28, 2024, 05:16:28 pm
content: QuoteHow is it broken? TCP is supposed to retry/recover etc.Not that this is relevant to the OP, for whom a wired approach is probably the best. Also, since he didn't mention routability (off-site etc), he could use ETH in the simple way people used it 30 years ago. I used to sell a German-made box which ran multiple RS232 channels over ETH and on the back of it were dipswitches for setting the MAC #. You get the ideaNot routable but probably switchable. You don't need IP for this. Just raw ETH.And POE is entirely separate and fairly simple because you are building power consumers only. You do have to implement the POE protocol; if you don't then you have to use chinese non-compliant POE sources

author: Siwastaja
author_rank: Super Contributor
timestamp: December 28, 2024, 05:32:38 pm
content: Quote from: peter-h on December 28, 2024, 05:16:28 pmI mean, TCP cannot retry/recover from all situations and indefinitely. TCP only guarantees order and integrity of data (no missing bytes, no duplicated bytes, no corrupted bytes). But TCP does not guarantee it can recover; if it can't, TCP closes the socket (to keep the promise of no corrupted/missing data). For user of TCP, this means calls like write(), read() return an error. After this, user needs to open a new socket, and SomeHow^tm understand what was the last transmission that went through; user needs to know how to recover their application from broken socket: in other words, synchronize the state between the two ends. (In many cases, but not all, this is as easy as "starting over" from initialization phase and just forget the task that was going on before the disconnect.)MQTT introduced a concept of three-level Quality Of Service, the idea of which is probably to handle this retrying over dead TCP sockets (after all, if the socket doesnotdie, then introducing additional ACKing over TCP makes absolutely zero sense). It is worded such that with QoS0, there is no guarantee of delivery; but of course, MQTT being on top of TCP, TCP itself gives quite strong guarantees (but see my comments about not recovering above). One could think that with higher QoS the messages would be retained and resent.Now, obvious thing to do when trying to create a more robust system is to disable clean_session flag and use QoS1 or QoS2 levels. And when you do that e.g. with PAHO Embedded C, you will see that it does not work; for example subscriptions are not synchronized. You will also see that at any QoS level PAHO Embedded C library is orders of magnitude less reliable than TCP, resulting in dying connection every few dozen minutes, due to bugs you need to discover from old ages old Github pull requests, then fix yourself (or maybe pull and merge those PRs). After fixing the bugs, then you need to think if you can fix the persisting session on PAHO, (e.g., add synchronization to topic subscriptions and message buffering lacking from the library and probably much more). So you choose not to do it, and only use clean_session and QoS=0, which then, after fixing all the bugs you can find, finally approaches the reliability of the underlying TCP socket. Then you implement broken connection recovery on your own, on top of MQTT payloads. Like you would have done on bare TCP socket anyway.And the problems are not limited to PAHO Embedded C. Similarly, libmosquitto needs a special handling code of broken connections, which you will face at some point. I have no idea where it comes from as I have not debugged the library internals, but it's there; there is no autoretry in the library.

author: peter-h
author_rank: Super Contributor
timestamp: December 28, 2024, 06:38:22 pm
content: Never played with this stuff myself butQuotejust means one has to handle errors at the application level.For example if somebody pulls out the cable for a couple of days, all talk of QOS is a waste of time. The application needs to retry say once a day, until it succeeds. Much simpler.Years ago I played around with satellite comms (Thuraya 9.6k dial-up) and when the link broke, no amount of lower level protocol could fix it.

author: Siwastaja
author_rank: Super Contributor
timestamp: December 28, 2024, 07:58:13 pm
content: Quote from: peter-h on December 28, 2024, 06:38:22 pmThat's exactly what I was saying. It's better idea to use a raw TCP socket and design whatever recovery your application needs, than to use MQTT hoping that it is somehow more reliable than bare TCP, which it isn't.

author: 5U4GB
author_rank: Super Contributor
timestamp: December 29, 2024, 08:09:14 am
content: Is MQTT really that nonexistent? It's true that I haven't seen it used much outside of HA but I just assumed there were deployments out there that weren't very visible, given that it's both an ISO and Oasis standard, with a considerable number of implementations out there, and support in significant infrastructures like Azure and AWS.

author: fchk
author_rank: Frequent Contributor
timestamp: December 29, 2024, 12:57:48 pm
content: The OP hasn't replied yet to the whole thread. Too much information?

author: peter-h
author_rank: Super Contributor
timestamp: December 29, 2024, 03:24:11 pm
content: QuoteIndeed, MQTT is closely linked to AWS spending (apparently) billions to push its IoT services. Maybe it is a failure but if it is I am sure Amazon won't be advertising thatBut there is the wider issue that a lot of IoT "growth" is just plain BS... It's like AII also feel that somebody deploying a million IoT devices on AWS will not care too much about the reduced-effort route of MQTT.This interests me because I've just finished a product which has TCP/IP, MbedTLS, and MQTT is something I will add if there is any interest. Actually same for CAN - the hardware support is there, so I will wait...The OP has probably posted this in many places. I am not wrong - google for" planning a communication system within a closed room "Stackoverflow deleted it (as they mostly do, in their anally retarded way): "This question was removed from Stack Overflow for reasons of moderation. Please refer to the help center for possible explanations why a question might be removed."Also here:https://www.reddit.com/r/embedded/comments/1hkklfr/can_vs_mqtt_best_protocol_for_a_reliable_and/etc

author: nfmax
author_rank: Super Contributor
timestamp: December 29, 2024, 05:08:54 pm
content: FWIW I used MQTT to connect movement sensors to keep a discrete check on my elderly father, who lives alone. Locally hosted broker, connections limited by firewall rules. Combined with Node-RED to give alerts and or status updates pushed to my phone. Uses internet communication, but no cloud involved

author: peter-h
author_rank: Super Contributor
timestamp: December 29, 2024, 06:05:24 pm
content: QuoteAIUI services like AWS are trying to position themselves into the broker space. This avoids the IoT devices being servers and visible on open ports. Lots of "internet security experts" get really hot under the collar in these discussionshttps://www.eevblog.com/forum/microcontrollers/how-would-you-do-a-heating-controller-iot-client-securely/This is far away from the OP's scenario. He posted more on what he's doing at the above reddit URL.

author: Siwastaja
author_rank: Super Contributor
timestamp: December 29, 2024, 07:00:49 pm
content: Quote from: peter-h on December 29, 2024, 06:05:24 pmWhat does this even mean? And billions what? I don't think they have put much anything to it. They just run the servers (brokers in mqtt speak), that's literally their job, just like they run whatever customers want to use.Our product uses MQTT (for no good reason really, but not a big thing enough to warrant a redesign), and we use Amazon. It's just a standard mosquitto broker running on standard virtual machine.Maybe around a decade ago there was something trendy in MQTT, when non-technical managers suggested it would work as some sort of common IoT compatibility layer, like, something which magically would make different IoT devices "talk to each other" - implying they wouldunderstandeach other, and do something sensible together. Of course there is nothing like this in MQTT, it's just a simple data sharing system with subscription patterns. For IoT devices to interoperate, one would need a pretty complex specification of different device classes and what their messages mean. Nothing even remotely like that in MQTT.Implied ideas that whole world's IoT devices would all connect to a single broker scare the shit out of me, especially since MQTT has no encryption, authentication or safety built-in at all (brokers and implementations implement their own non-standard solutions of course, which we also use).This kind of hype (which I also guess peter-h refers to) is what I refer to when I say that MQTT is forgotten and projects frozen. Of course it's still used for various projects, but the hype is long gone.We use MQTT on top of a simple point-to-point link - devices connecting to a broker, and custom application server also connecting to broker, broker acting as a simple middle man. Devices do not communicate with each other; they could instead connect to the very same custom application server directly.

author: 5U4GB
author_rank: Super Contributor
timestamp: December 30, 2024, 04:46:53 am
content: Quote from: fchk on December 29, 2024, 12:57:48 pmIt's actually been a quite valuable discussion, particularly about the pros and cons of MQTT, even if it wasn't useful for the OP :-).

author: 5U4GB
author_rank: Super Contributor
timestamp: December 30, 2024, 05:05:32 am
content: Quote from: peter-h on December 29, 2024, 03:24:11 pmIt'd be interesting to hear back at some point what it is that users are really interested in. We follow a similar strategy (for a very different product line, you're not giving up competitive intelligence :-) of implementing what users want, and conversely slowly deprecating what marketing asked for but no-one ever actually uses. This is software-side so in one release it becomes optional-to-enable, then in the next disabled-by-default, then removed from the object code (via #ifdefs), and finally removed from the source code.The trick is being able to guess what bloat is entirely optional and not put it in in the first place, which we've become better at over time.

author: Siwastaja
author_rank: Super Contributor
timestamp: December 30, 2024, 10:03:46 am
content: Quote from: peter-h on December 29, 2024, 03:24:11 pmIf you managed to integrate lwip and mbedtls, then mqtt is order of magnitude simpler. It's a really simple protocol with some bytes of header fields, the whole specification is a few pages long*. For example, PAHO embedded C implementation is 2500 LoC; compare that to 120 000 LoC of mbedtls.So it's pretty manageable. If your customer needs MQTT, it shouldn't be a biggie to offer it.*) edit, OK, this is 81 pageshttp://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.pdf, but it includes a lot of boilerplate, long examples etc.

author: peter-h
author_rank: Super Contributor
timestamp: December 30, 2024, 02:50:07 pm
content: Someone was paid to implement LWIP and MbedTLS (TLS 1.2) on my project. This stuff is incredibly complicated. I spent months just optimising the code afterwards, for stuff like the ETH low level buffering, the infamous "low level input/output" code, all kinds of stuff, sorting out buffers in LWIP (horribly undocumented stuff).QuoteReally? Not possible surely. X509 (MbedTLS) is a huge chunk of code. I looked up PAHO - double dutch to me...I never looked into this but I gather MQTT can also run X509 or some subset of it, but you have to add it in.ST offer MQTT with Cube IDE but it is probably crippled/dud. Just like their HTTPD; a contractor was assigned to produce an HTTP server and after some months I chopped it and wrote a simple HTTP server myself.If a customer wants something and is willing to buy x 100 boxes, one can throw some money at it

author: Siwastaja
author_rank: Super Contributor
timestamp: December 30, 2024, 04:04:45 pm
content: Quote from: peter-h on December 30, 2024, 02:50:07 pmYou would run MQTT protocol over encrypted and authenticated TCP socket (this means: on top of TLS); MQTT would have no idea about authentication or data security. Some brokers (like mosquitto) have their own, completely non-standard ways to deal with authentication, for example, such that certain client can only subscribe and publish to a certain topic name. It's a hack; mqtt was never designed for secure communications (and it doesn't need to be, that's why we have layering of protocols)QuoteYeah - HTTP can be, in simplified case, made very simple. MQTT is similarly simple. Especially if you only need a small subset, you would write it in a weekend; you are definitely smart enough to do that.By subset, I mean you could maybe choose not to support MQTTs plain-text password authentication feature, for example

author: peter-h
author_rank: Super Contributor
timestamp: December 31, 2024, 08:40:52 am
content: Surely MQTT without security is a commercial no-go. Everybody wants to tick all the boxes nowadays. So what are you really gaining, over a "straight" LWIP + MbedTLS Client implementation?

author: Siwastaja
author_rank: Super Contributor
timestamp: December 31, 2024, 11:06:15 am
content: Quote from: peter-h on December 31, 2024, 08:40:52 amAs I have said, you get the subscription-filter protocol and some existing tools like thebroker; a server which takes in a message and delivers it to those other MQTT clients who have subscribed to it (filtering). You can do the same on your own, butifwhat you need is already exactly covered by MQTT, then it's not a bad choice.In many real cases having this one-to-many distribution sounds good, until you realize that other clients do not want to run MQTT clients to get those raw messages generated by the IoT devices, instead they want cloud-processed data accessed through HTTPS (web page) or native mobile app; or have custom API or database queries. In this case you have to add your own application-specific server, to which the embedded devices can connect to: device<->server becomes a simple one-to-one link. In such case, MQTT has very little to offer, bare TCP socket does the same with less overhead.

author: peter-h
author_rank: Super Contributor
timestamp: December 31, 2024, 11:55:32 am
content: QuoteYes; referring to that "heating controller" thread, this is appropriate. But since you already need LWIP+TLS (by "need" I mean to please customers who are "internet security experts") the advantage of MQTT is only in that you have ready to roll packages for the server code. Not for the IOT device, really, once you have a working TLS Client.In reality, I think the server code will involve a lot of extra work anyway, because you need to offer, and carefully manage, stuff like firmware updates. And since OTA FW updates have the potential to blow up your companyyou need to control the distribution with great care. For example if you have multiple customer device blocks, you want to update the smallest customers first.QuoteI think this is a rare requirement. Going back to the "heating controller" (which I think must be a classicpracticalIOT application scenario) the whole reason behind this topology is to avoid exposing the IOT boxes on open ports, to limit the exposure to a robustly configured and well protected server, which passes messages to the clients (and they collect them periodically by "checking in"). Perhaps MQTT supports this?

author: Siwastaja
author_rank: Super Contributor
timestamp: December 31, 2024, 12:23:48 pm
content: Quote from: peter-h on December 31, 2024, 11:55:32 amMQTT is application layer protocol. How you prepare a secure TCP connection between your cloud server and IoT device is up to you, MQTT does nothing related to that. Of course libraries like libmosquitto (on general purpose PC running e.g. linux) support reading cert and key files and open a TLS over TCP connection for you. But this isn't many lines of code anyway.A sensible IoT heating controller would connect to the server securely so that the heating controller is TCP client and the server is TCP server. If you want to use MQTT for whatever reason here, then the server is just called "broker" instead and that's it, you still need to arrange the secure TCP connection between the two somehow. Here again some brokers like mosquitto offer a way, via configuration file, for certain clients only to access certain topic names, but it has not much to do with MQTT protocol because A) it's not in the standard, B) it's not even a protocol extension, it's all happening on the TLS/TCP protocol level, based on the CN field of the certificate.

author: 5U4GB
author_rank: Super Contributor
timestamp: January 01, 2025, 11:36:09 am
content: Quote from: Siwastaja on December 31, 2024, 11:06:15 amAlso in stuff I've worked on, when given the choice between MQTT and having to digest 100k of XML gloop over a REST API in order to extract a single value somewhere, I'll take the MQTT any day.