Is Modbus suitable for wall switch applications?

Hi everyone,
I’m trying to upgrade some commun “dumb” wall switch that we can find on any hardware store with the help of some microcontroller.

I’m trying to find the best topology / protocole to use so the wall switch can communicate with the breaker box or some centralized logic that will operate actuators.

until now I was using TCP/IP based protocole (like mqtt) to achieve automation, but deploying cat5 / hub based topology is a real pain.

so I was considering using bus instead.

when I was searching for some RS485 based protocole, Modbus showed up several times and I started to look into it.

the Slave / Master topology seems to be really suited to drive actuator (like valve, motor, relay) but what if a slave is actually a sensor that will report events (like button presses)

has I understood slave devices cannot talk to master without the master initiated the communication first.

so how can ModBus switch can report events?

Is the master polling each slave to see if there was a button press?

Thanks for your help

:love:
 
Hi everyone,
I’m trying to upgrade some commun “dumb” wall switch that we can find on any hardware store with the help of some microcontroller.

I’m trying to find the best topology / protocole to use so the wall switch can communicate with the breaker box or some centralized logic that will operate actuators.

until now I was using TCP/IP based protocole (like mqtt) to achieve automation, but deploying cat5 / hub based topology is a real pain.

so I was considering using bus instead.

when I was searching for some RS485 based protocole, Modbus showed up several times and I started to look into it.

the Slave / Master topology seems to be really suited to drive actuator (like valve, motor, relay) but what if a slave is actually a sensor that will report events (like button presses)

has I understood slave devices cannot talk to master without the master initiated the communication first.

so how can ModBus switch can report events?

Is the master polling each slave to see if there was a button press?

Thanks for your help

:love:
Hi ALL

Sandra,

You can have a look, on the following article:

It contains some of the answers, of the questions you posted here.
https://maker.pro/raspberry-pi/projects/an-automated-light-switch-system-for-smarthomes-that-anyone-can-use


Surely it can help you !

Controlsguy25
 
Hi ALL

Sandra,

You can have a look, on the following article:

It contains some of the answers, of the questions you posted here.
https://maker.pro/raspberry-pi/projects/an-automated-light-switch-system-for-smarthomes-that-anyone-can-use


Surely it can help you !

Controlsguy25
the article is interesting but its not exactly what I want to achieve

On this article, this gentleman is using a Modbus slave to read the state of a double output relay and an output to simulate a button press so he can turn on / off his light.

that doesn’t tell me how can a Slave device can report button state (in the case of toggle switch) of button press (for momentary switch) to his master...

my problem is that I don’t understand how with the Modbus protocole a master can be “aware” of a button press of a daisy chained slaves with switches.
I’m assuming that the master must poll every single slave all the time to read some discrete input state but since I don’t see any real life proof of concept it must be because modbus protocole isn’t suited for that?

I have a hard time figuring out if the polling of every slave can cause bandwidth overhead or if this is something that Modbus can deal easily
 
the article is interesting but its not exactly what I want to achieve

On this article, this gentleman is using a Modbus slave to read the state of a double output relay and an output to simulate a button press so he can turn on / off his light.

that doesn’t tell me how can a Slave device can report button state (in the case of toggle switch) of button press (for momentary switch) to his master...

my problem is that I don’t understand how with the Modbus protocole a master can be “aware” of a button press of a daisy chained slaves with switches.
I’m assuming that the master must poll every single slave all the time to read some discrete input state but since I don’t see any real life proof of concept it must be because modbus protocole isn’t suited for that?

I have a hard time figuring out if the polling of every slave can cause bandwidth overhead or if this is something that Modbus can deal easily
OK so here you have it :
https://community.openhab.org/t/combine-mqtt-and-modbus-in-switch-item/81854

here some quotes:
If you were using MQTT and Modbus version 2 bindings, you could use a follow profile.


The modbus binding is only going to respond to a command, not a state change, so you need to find out how to get MQTTv1 to produce a command on input.


I don’t want to use rules for switches, it has about 100 lines (15 switch functions) and if I have 5-10 switches, the rules respond slowly.
Something else wrong there. This is not a difficult job. You might need to think about if really you want both devices updating to the same Item. Remember Modbus polls regularly.

Here is a example for polling ( temperature sensor) :
https://community.openhab.org/t/solved-mqtt-1-x-follow-channel/64155

You should have a check o, this site as there some threads on MTTQ and modbus combination.

Dont know if that article can give you, some of the answers that you need, but it can be a precious information .


Also , you should get if not done yet manuals form Vendors about the products they can propose.
You will surely get more answers/ informations about how it works.

That a good subject for a thread, myself i gonna study this for future installation, and see what it can do for me.

Thats all i can do for the moment,
Controlsguy25
 
OK so here you have it :
https://community.openhab.org/t/combine-mqtt-and-modbus-in-switch-item/81854

here some quotes:
If you were using MQTT and Modbus version 2 bindings, you could use a follow profile.


The modbus binding is only going to respond to a command, not a state change, so you need to find out how to get MQTTv1 to produce a command on input.




Something else wrong there. This is not a difficult job. You might need to think about if really you want both devices updating to the same Item. Remember Modbus polls regularly.

Here is a example for polling ( temperature sensor) :
https://community.openhab.org/t/solved-mqtt-1-x-follow-channel/64155

You should have a check o, this site as there some threads on MTTQ and modbus combination.

Dont know if that article can give you, some of the answers that you need, but it can be a precious information .


Also , you should get if not done yet manuals form Vendors about the products they can propose.
You will surely get more answers/ informations about how it works.

That a good subject for a thread, myself i gonna study this for future installation, and see what it can do for me.

Thats all i can do for the moment,
Controlsguy25
thanks a lot
 
thanks a lot
You are welcome !

Do not hesitate to share with us, what your found interesting for this application.

I was surfing and the web about the subject, there is many interesting informations!

One should get the correct overview of the system, see what can be achieved with the proposed equipments and then study and find the best solution !

Controlsguy25
 
>I’m assuming that the master must poll every single slave all the time to read some discrete input state but since I don’t see any real life proof of concept it must be because modbus protocole isn’t suited for that? I have a hard time figuring out if the polling of every slave can cause bandwidth overhead or if this is something that Modbus can deal easily

Your assessment of Modbus operation is correct. It is a master/slave polling protocol, where all slaves are silent unless spoken to by the master. The only method of determining a state change in a slave is for the master to constantly poll each slave for its status, one at a time, each in turn. That process is definitely bandwidth overhead, as you call it.
 
Ok thanks for confirming that.
I’ll try to find a suitable protocol for this application. Maybe using KNX instead?
I’ve always stay far away from KNX since every single bit of hardware / software cost a lot of money... but if there is a way to directly flash each microcontroller and avoid using any kind of ETS software maybe this protocole is better...
 
Hi everyone,
I’m trying to upgrade some commun “dumb” wall switch that we can find on any hardware store with the help of some microcontroller.

I’m trying to find the best topology / protocole to use so the wall switch can communicate with the breaker box or some centralized logic that will operate actuators.

until now I was using TCP/IP based protocole (like mqtt) to achieve automation, but deploying cat5 / hub based topology is a real pain.

so I was considering using bus instead.

when I was searching for some RS485 based protocole, Modbus showed up several times and I started to look into it.

the Slave / Master topology seems to be really suited to drive actuator (like valve, motor, relay) but what if a slave is actually a sensor that will report events (like button presses)

has I understood slave devices cannot talk to master without the master initiated the communication first.

so how can ModBus switch can report events?

Is the master polling each slave to see if there was a button press?
The solution is exactly the same as with any other master-driven protocol. Look at it this way: your USB keyboard and mouse can’t transmit by themselves either. What happens instead is the USB host is sending a periodic read request to the device endpoint, and the device replies with a small amount of data (up to 64 bytes), but most of the time it replies that it has 0 bytes of data.

Incidentally, this makes USB in essence a hard real time protocol with distributed clock reference - all devices hear the host at the same time, and they all reply within very tight deadlines. A lot of higher level USB stack code hides this fact, but USB is a pretty neat base for industrial real-time control uses if you can get your hands “dirty”.

Full speed USB has an 8kHz cycle by default, for example. Even the stupidest USB thumb drive is in essence a hard real-time device in terms of low level protocol, and it can be leveraged for some wonderful things. Doing coordinated motion with properly designed USB stepper drivers, for example, is almost trivial since the real time aspects are handled by the ubiquitous protocol.

Modbus works the same in terms of central polling, of course, except that there is no direct support for buffers, so if the host wants to read up to 64 bytes, it must be reading a memory area with 65 bytes in it: the count + 64 bytes of potential data, unused bytes are junk if there’s no data available (can be zeroes or some other “nice” value if the device firmware is kind to you).

I’m not sure if it’s worth “killing” Ethernet in your case. Given how little power your devices consume, a pass-through passive 24V PoE would be ideal, since it’s very easy and cheap to get working. Each device would need two Ethernet ports, and it could implement a switch or a hub depending on what you prefer. A software defined switch could be simple enough if you have a microcontroller with two Ethernet PHYs. Or get a pair of single PHY microcontrollers back-to-back, joined with fast SPI. Whatever is easiest to get working. Or even forward packets between two Arduino Ethernet shields - this can be done with reasonable bandwidth if you use DMA.

If you wish to implement this from scratch then I suggest going with IPV6, since it’s a much more straightforward protocol. You don’t even need to handle DHCP - use auto-assigned link-local addresses and deal with router advertisements to get the gateway. IPV6 doesn’t use subnetting same way that IPV4 would, and is easier to deal with in practice. Plus you’d be learning a valuable skill - lots of people are mentally stuck in IPV4 jail, and don’t appreciate the simplicity and power afforded by IPV6.

For example, it would be easy to put your wall switches directly on the public IPV6 Internet and use your router’s firewall to gate the access. This removes the need for any kind of port forwarding etc, and can be made much safer than the schemes that intermingle firewalling with NAT. With IPV6 you don’t need NAT for anything at all. This is powerful for remote diagnostics since you don’t need VPNs: connect to your router’s public https interface, log in, allow your public IP address access to the internal network, and then you can access anything inside without any sort of friction: both you and your devices have routable IPV6 addresses. When done troubleshooting, close the firewall and that’s that.
 
The solution is exactly the same as with any other master-driven protocol. Look at it this way: your USB keyboard and mouse can’t transmit by themselves either. What happens instead is the USB host is sending a periodic read request to the device endpoint, and the device replies with a small amount of data (up to 64 bytes), but most of the time it replies that it has 0 bytes of data.

Incidentally, this makes USB in essence a hard real time protocol with distributed clock reference - all devices hear the host at the same time, and they all reply within very tight deadlines. A lot of higher level USB stack code hides this fact, but USB is a pretty neat base for industrial real-time control uses if you can get your hands “dirty”.

Full speed USB has an 8kHz cycle by default, for example. Even the stupidest USB thumb drive is in essence a hard real-time device in terms of low level protocol, and it can be leveraged for some wonderful things. Doing coordinated motion with properly designed USB stepper drivers, for example, is almost trivial since the real time aspects are handled by the ubiquitous protocol.

Modbus works the same in terms of central polling, of course, except that there is no direct support for buffers, so if the host wants to read up to 64 bytes, it must be reading a memory area with 65 bytes in it: the count + 64 bytes of potential data, unused bytes are junk if there’s no data available (can be zeroes or some other “nice” value if the device firmware is kind to you).

I’m not sure if it’s worth “killing” Ethernet in your case. Given how little power your devices consume, a pass-through passive 24V PoE would be ideal, since it’s very easy and cheap to get working. Each device would need two Ethernet ports, and it could implement a switch or a hub depending on what you prefer. A software defined switch could be simple enough if you have a microcontroller with two Ethernet PHYs. Or get a pair of single PHY microcontrollers back-to-back, joined with fast SPI. Whatever is easiest to get working. Or even forward packets between two Arduino Ethernet shields - this can be done with reasonable bandwidth if you use DMA.

If you wish to implement this from scratch then I suggest going with IPV6, since it’s a much more straightforward protocol. You don’t even need to handle DHCP - use auto-assigned link-local addresses and deal with router advertisements to get the gateway. IPV6 doesn’t use subnetting same way that IPV4 would, and is easier to deal with in practice. Plus you’d be learning a valuable skill - lots of people are mentally stuck in IPV4 jail, and don’t appreciate the simplicity and power afforded by IPV6.

For example, it would be easy to put your wall switches directly on the public IPV6 Internet and use your router’s firewall to gate the access. This removes the need for any kind of port forwarding etc, and can be made much safer than the schemes that intermingle firewalling with NAT. With IPV6 you don’t need NAT for anything at all. This is powerful for remote diagnostics since you don’t need VPNs: connect to your router’s public https interface, log in, allow your public IP address access to the internal network, and then you can access anything inside without any sort of friction: both you and your devices have routable IPV6 addresses. When done troubleshooting, close the firewall and that’s that.
Thanks for your reply.
The idea of having a device with an integrated switch so I can daisy chain the devices with TCP/IP is really interesting.
I’ll dig into that since now I’m on vacation.

I wonder if this is possible to achieve using the “famous”WIZnet W5100. This is the Ethernet controller that I’m the most familiar with.

thanks everyone for your help, i really appreciate the time you take to write me back
 
Hi @Sandra, I'm seeking the same information as you for a home automation project and so far my conclusion has been that Modbus RTU over RS-485 is indeed the best solution, mainly because of its popularity and thus the ability to talk to various third-party devices without hassle – you can even get inexpensive capacitive touch switches from China that seem to work great (they are marketed towards hotels and so it seems that the same protocol + physical layer combination is used in professional large scale applications).

Please, keep us updated about your progress, especially in case you find a more robust solution that is easier to work with. I've been considering 1-Wire from Maxim as well as KNX but Modbus over RS-485 seems to be the best open solution I've been able to find.
 
Top