Openhab as Modbus Slave

Setup, Configuration and Use Beginners
1

Hi

I am using Openhab on a Raspberry Pi.
I use the Modbus TCP Binding. As i understand It can only Act as a Modbus Master.
Is there any way i can provide data to a device that can also only act as a Modbus Master?

Detailed explanation of what i want to achieve:
(in case anyone has a “better idea”)

I have an Inverter that Modbus Master(Solaredge…). That that one Master is Currently Openhab and everything works fine.

Now I have a HeatPump that theoretically can modulate and use the excess Solar Power to “Overheat” my warm water storage. If i let the Heatpump Querry data directly from the Inverter I can’t do it via Openhab anymore.
(I know there is the solaredge API i could use for getting data but that cant do all that i require (eg. Change the ehavior of the Battery depending on Weatherforcast, etc…)

So since i already have all the Sunspec Data in Openhab i thought maybe there is a way to act as Slave and Provide this data to the heatpump controller.

Greetings
Manuel

1 Like
2

No, openHAB acts as Modbus slave (only). Towards the inverter and towards the heat pump.

Combining what you laid out is possible but don’t underestimate this please, it’s a challenge to implement comprehensively.
I’m offering an energy management system based on openHAB https://storm.house/ems that does all of this and there’s an awful lot of things you need to be aware of.
It has an untested Solaredge implementation. I’m still looking for a pilot customer to
To be clear, that’s a commercial offering.
You would get the installation/customization part for free in return for your help.

3

Ehem… Think you confused something @mstormi.

Definitely the openhab Modbus binding only can act as MASTER and can contact slaves vio modbus TCP, modbus RTU over TCP, modbus serial in the modes RTU, ASCII and BIN…

And yes as the thread opener correctly said, some slave devices cause issues if multiple Masters try to contact them or when they only can act as master themselves… Also some devices do support being master and slave at the same time, some don’t… Some modbus TCP devices offer a second (or even more) ports to be able to react to different masters or being master on one port and slave on the other… But not all do that… A modbus slave mode would be really interesting for openHAB and would increase the usage a lot…

I am not sure about the exact way to go, but there are more or less expensive and elegant possibilities to get that done, as there is according to my knowledge no modbus binding, which makes openhab act as a slave…

Option one: try to make all devices being a slave and distribute the necessary data via openhab rules and channel links. Problem, doesn’t work for all, e. g. KOSTAL Piko CI, if it wants to use the internal grid power limitation, needs to be master towards the Kostal Smart meter, in slave mode you can’t write the grid power data to the inverter… It’s solvable, by calculating the proper powerlimit inside openhab and write that value to the CI in slave Mode…

Option two: some devices offer serial and tcp modbus interfaces and can configure them different, so let the inverter be the master on the serial and slave on the tcp interface can work.

Option three, use a Comercial modbus gateway… One would need a gateway, that is slave on both sides (not sure which one does that) and need to configure it that it emulates the registers to be written by the master… May need some reverse engineering to figure out, what the master writes to which register. And what he wants to read there…

Option four: Use (commercial or free trial) of OAS Open Automation Software as a gateway (on a own pi or maybe on your openhab device paralell), it can act as a modbus master and and as a slave… And maybe most interesting it can, if configured right convert everything for and back to mqtt and use the mosquitto on your openhab as the broker…

Option five: find something that is really free, that acts as a modbus slave and communicates as e. g. Mqtt, I am sure there is some software out there, which does that and may even run on a Esp, a Adruino (AT Mega) or a pi zero.

Option six: programm a slave yourself and access it by the exec binding…

I am personally investigating option 4 and 5 atm…

4

You’re right, technically speaking I used the wrong term. But master/slave is misleading in this context anyway as it isn’t about layer 2 communications and I was merely responding to the fact that openHAB has the active (in terms of comms: client) part and all other devices (inverter, heat pump, whatever) are queried/controlled (in terms of comms: server) as I think that’s what the question was really about.
The inverse is not possible because openHAB has not implemented that part, also it wouldn’t make sense to implement it. openHAB is the controller, never the controlled device.

Thing is, Modbus is a point-to-point protocol that works fine as long as you only have two participants, one server and one client.
But once you have a third party like an energy management system (which is what openHAB is in that context) come into play, you need multiple point-to-point connections (Modbus or other like via HTTP).
Unfortunately most implementers of inverters don’t think beyond their immediate needs (or don’t want to because e.g. they want to be the energy manager themselves) so you often hit limitations whenever that applies.

It’s an architecture matter.
The main point is, all the logic has to take place in a SINGLE central unit, the energy management system. It queries and controls all energy devices via separate connections.
If you do it that way, you are fine with what’s implemented in OH today and none of your options are needed. And as long as you adhere to that principle of “single CPU” you will not start hitting implementation issues such as limited number of connections.
But once you add any form of parallel processing, you will.

In our EMS we query inverters via Modbus/TCP while the inverter (usually) in turn queries the meter via a different i.e. separate Modbus link using RS485 and provides the relevant values back through the former connection. If that inverter-meter link is not available, I need to query the meter myself which then is another separate Modbus/TCP connection.
As our EMS is openHAB based, you can reuse its Modbus connections (or the items, actually) and this even works from a remote openHAB instance.
If it wasn’t (like is if you are using any other commercially available EMS or other Home Automation system), you would have to implement your own querying in addition to the commercial system’s one, again running into limitations.

5

Thanks to Both of you,

Sorry for the late reply i had a really busy week.

My heatpump will hopefully be installed in a few weeks.(planned is the week from the 11th september)

@Markus_Oliver_Thur : I will explore option 4 and 5

@mstormi i will also try out your demo at that time

Greetings

6

Sorry to start that discussion, but this is the common missunderstanding of MODBUS and the MODBUS Specification…
MODBUS is NOT a Point to Point Protocol, it is a serial BUS protocol introduced in 1978. And mainly used with the EIA-485 (TIA-485, RS485) serial Bus introduced 1983, until MODBUS TCP emerged to use that protocol on top of an TCP Network.
The main issue with Modbus on RS485 Bus is that RS485 only allows one active sender at a time on the bus and leaves it to the protocol to make that sure. The easiest way to get that done was to allow only one BUS MASTER on a Bus, and make the BUS Slaves to be quiet if not asked by the Master. And that is what modbus till today does…
Both include some kind of naming confusions that till today are on the market, which even resultet from weakly written specifications on that… But there is on one MODBUS:
1 BUSMASTER (the client)
up to 32 /128 / 252 BUSSLAVES (the servers) (dependig on the physical metrics of the bus used)
with a bit efford in coding you may be able to syschronize masters in a way, that two masters will not interfere with each other.
With modbus TCP, it is possible to act as a master and a slave on the same ethernet interface at the same time. The most easy way is, that a modbus master or slave implementation can run on any TCP Port, this doesn’t need to be the common 502, it can be any port and paralell. And there I am with you, Producers of inverters tend to provide pretty weak implementations. And even if they fix it, they still have weaknesses… And yes, if a device needs to be in an environment with an “generating plant controller” and it is not able to be master and slave at the same time, it has to be slave, cause the “generating plant controller (deutsch EZA-Regler)” needs to be the Busmaster (the client). He querries the “smartmeter” and “commands” the generator. And yes openHAB can nicely act as a “uncertified generating plant controller”, but especially as Producers still try to bind you to their products by stupid implementations (e.G. the modbus communication of KOSTAL Enector wallboxes, which misuse a Modbus RTU on RS485 connection as a serial point to point connection) and as long as there are more or less stupid regulations that force your plant control to be certiefied or to be internally in the inverter, there will be those issues… And it would be really great if openHAB could be a MODBUS Slave also, which shouldn’t be that tricky at all… It’s pretty much the same as being a modbus master, with the exception, that the bridge doesn’t need to initiate the querries, it just needs to wait for a request from a master.
This would make openHAB really powerfull, as it could act as a modbus gateway then.
And yes, of course, the configuration of that wouldn’t be that easy.
Let’s asume there is a inverter in master mode, that wants to know the total power to grid value and there is a smart meter in master mode that publishes the total power to grid value. So u may need (asuming sunspec 103 and 202 are used) two config files for the modbus slave implementation, defining two registers each where the inverter and the meter want to write / read from the values of “Total Real Power” and “Real Power scale factor” (unless the slave impl just serves all legal modbus register adresses, which is maybe ram consuming but failsafe) then u need to define two bridges two the two instances of modbus slave from the “hypothetical” Modbus Slave binding. And the u need to define four modbus things on top of the bridges, which then define which value to read and do a potential value transformation. And those four channels u need to link to at least two items, if u don’t need further smart manipulation of them (then u need at least four items).
But voila, you are able to exchange data between two masters, a master and a incompatible slave, or two slaves (which is the only thing u can do at the moment).

7

That’s not right in terms of the ISO layered comms protocol specification.
Your two statements here are about different layers. It’s BUS in terms of the physical/electrics layer. But it’s P2P in logical terms (as opposed to P2MP i.e. point-to-multipoint like is say IP multicast).
Short of broadcasting (which is not used in regular comms), you can only ever address ONE destination address. Not a group of destinations.
To send say an information from the smart meter to the inverter and to openHAB, you will need two messages even if all three devices were on the same physical bus.

As for the rest of your post, apart from that I don’t see the benefit of OH being a slave, you seem to want to misuse openHAB as a converter toolset but that it is not designed to be. It would be quite a violation of the underlying software design principles in fact.
openHAB is a smart home controller and always the master in a higher layer sense: it’s the entity to control and drive communications with devices, irrespective of what’s the protocol to be used for that, Modbus or ZigBee or HTTP or other.
The openHAB instance itself never the slave entity to be controlled by others.
That’s how the software is built and this is also a reason why any hypothetical implementation is a lot more challenging than you think (if reasonably possible at all).
This is Open Source. You are welcome to contribute with a pull request yourself to implement what you want. I would not mind and maybe others see a benefit for it.
But please don’t expect any openHAB developer to jump onto this train of yours.

8

What you say is fairly subjective, because as openHAB name says, it is “Home Automation Bus”, thus it does not assume any direction of communication. Making OH a modbus slave opens up OH data to be consumed by industrial automation controllers which lack/miss radio capabilities.

What about homekit and hueemulation which exposes openHAB items using a software specific protocols so other homekit/hue-compatible tools might interact with them?
From design point of view there is no limitations on HOW an item can be signaled. By default it is a HTTP, but from both logical and technical point of view it can be anything, even a TCP stream. This is something which does not fit a binding concept but we have additional category of “io” extensions such as mentioned hue emulation bridge to serve that.

What about hue emulation, alexa, google speakers, and others? How about remoteopenhab binding which turns one openHAB instance into a slave of other? What you say, given above points, is simply not true.

1 Like
9

As I said, many not understanding it since introduction. Modbus is a Master / Slave Bus Protocol originally intended for the RS485. Including boardcast. The boardcast adress is, believe it or not 0… as in most bus systems with boardcast… Yes u can’t multicast… But multicasting is not something that specifies a bus… And in most implementations a multicast does not state several adresses of abus, but just sends multiple unicasts. But this is another issue… And yes it is a Master / Slave Bus protocoll which in the ISO layers does a “violation” of strict layer seperation between hardware and protocol. That is / was a design issue, which u find in may other busses also… Furthermore it has to live with the limitation of the the RS485 it is designed for, that u don’t have a roper busy signal on the physical layer, but that is an issue many protocolls have to live with… And since the introduction of Modbus TCP it gets even more strange, including the implementations that are used and misused very often…But it is still a bus… I can adress and boardcast multiple slaves that exist on a specific IP Adress and port, but most devices are just one device.

And the benefit of OH being a slave is pretty easy… It improves the connectivity and it is not against the design of OH… If that would be true, than a lot of OH plugins would violate the design, cause it is a Automation Broker, not a Automation Server or an automation client. And it already does translate between different protocols, cause thats exactly what it does… And there are bindings, that act as the master of a communication and there are bindings that act as the slave of the communication. There are also bindings that act in a peer to peer communication style. Like MQTT binding is using the publish subscribe system obviously, so it is in classical terms master and slave of the communication at the same time… It determines itself, when it wants publish something, most probably a command and the broker decides when a item that was subscribed gets published to OH. Then the OH binding itself… The remoteopenhab binding One: of the two openhabs involved definitely waits for the other to querry him… So it’s acting like a modbus slave, waiting for the master… And even the rules system itself… The rules wait for an event to fire and do not actively poll for a change… (unless i use a timer as trigger and poll for something)… Ups… does both also… And the REST API… Definitely Openhab is not the Master of the REST API communication, it is the communication slave/server, waiting for some master/client to ask for something… So your argument it’s against the design and idea of openhab to be a modbus slave is more than weak and even wrong…

And now again what to do with it, because most of the producers of MODBUS enabled component give their products only the ability to act as a slave or as master (some allow at least that u configure the behaviour) u need to be a slave, as soon as u have a device that needs to be the communication master, and vice versa u need to be or have a master if a device only can act as a slave. Among the devices that can configure their behaviour, most of them don’t allow to be master and slave at the same time, even it is possible on the TCP version of Modbus Protocol (on a physical RS485 connection it is nonsense to allow both modi at the same time on the same wire), and then there are devices on the market that can do that, or are even intended to do exactly that.
Just examples:

  • VIPA S7-300 from factory only can be modbus master (and yes we can and want bind a S7 PLC to openhab via the Smatic binding)
  • Omron Celsiux Temperature controller only can be slaves
  • Kostal Piko CI Inverters can be master or slave, but as soon as they shall form a cluster one needs to be the master and the others need to be slave. so in cluster mode i can’t acces the one which leads the cluster, but I also can’t acces the slaves, as they (by weak implementation of the Modbus TCP Protocol) crash if they have concurring requests from two different masters.
  • the Kostal Smart enrgy meter also can act as a master or a slave, which is need as sometimes the inverters are master and sometimes they are the slave… Yes I can make all being slave and being querried by OH, but then OH has to do the task of managing the cluster completely… And that’s maybe exactlynot the intention of OH. In this scenario OH as a slave would be much better and closer to the intention of OH, especially as it is NOT a certified energy manager. This scenario even gets more strange if there is a certified enrgy manager involved, because then this one takes the role of the master, but I still want to use the data from the manager to trigger reactions of the home automation components…
    What would a OH Modbus slave binding have to do. It would first of all have to have a running modbus slave service with configured / configurable registers/coils (word and bit) and as we want to be able to have different instances running configurable port and Modbus ID. then the binding would need to provide a bridge item with configurable channels for those registers. Those channels then can be connected to Items… Ok there it needs a little effort, as one item can represent data larger than 16 bit, DWords or even strings, so it also needs to provide channels that can connect to a cluster of registers. Whenever now the Master writes to a writeable register, and update event triggers from the channel and updates the item… Whenever an item receives an command or update in openhab, the binding has to update the value in the registers of the modbus slave instance or not, according to the configured connection between channel and item… Not that much different from the Master binding, isn’t it? Only real difference to the master binding is, that the bridge from the existing modbus master binding polls the slaves in the configured manner and updates the connected items because of the received answer.
    And definitely not violating the Idea of an Open Home Automation Broker… That is exactly what it has to do… being open (supporting as many protocolls as possible in a configurable and non properitary way), supporting devices that are used in Homes (OK, S7 PLCs maybe not, but LOGO! does use the same protocol and both are supported by OH), doing automation (it does and it does in an very open way, as I can impement my automation in nearly any language, and if not, I still can use the exec binding) and it is a Broker, which is neither a classic client, nor a classical server, it just understands and supports known services and takes the role of server or cliet as needed.
    And yes of course, it shall be the higher level coordinator of the automation system, which in reverse means, that tasks that can be performed by the underlying devices should be performed by the underlying devices and only if data from another eco-system are needed it shall intervene… And it may be used in order to get rid of the need for external cloud services… But only may, it’s a side effect of the broker, as it also can interact with external cloud services…

And yes I am taking on your invite to do it, but maybe someone else with more experience with OH is also interested in it… And the first step is always to discuss things in such a project and if there is a “no it is against the design idea” this definitely first has to be clarified and sorted out, before a change to that direction is done, by anyone… (And I am aware this is a big weakpoint of many software developed in teams… commercial, as well as community).

10

Sorry, that I doubled it up, what you already said…

11

You got me wrong.
I didn’t say (or if you think I did: I didn’t mean to say it) that OH is the always the (protocol) master in all of its communications.

Unlike all those protocols to control actuators and to obtain input from sensors,
REST, Home and Alexa however are special input interfaces.
The point is that openHAB isn’t built to take generic commands from other controller entities except on those channels specifically built to serve as input interfaces (and they’re very much limited in terms of what you can instruct OH to do that way).

Modbus is not any valid input channel and won’t become one by reversing master and slave i.e. the communications direction.
OH is not designed or built to take commands via Modbus from another controller like an SPS
(openhabremote obviously has a very special purpose let’s leave that out of comparisons).
OH is designed and built to control other controllers but not that those other controllers attempt to control OH. It’s the one ring to rule them all, asymmetric by design and controls the relations to all devices. It’s never a slave in that sense. That’s what I wanted to express by calling it a ‘master’.

Again I don’t see the point in OH being a Modbus slave until you want to remote control it, and that we don’t want to.
Now I’m not a binding maintainer to decide but I guess they think along the same lines and wouldn’t be accepting any such addition to aim at doing that.
If you seriously think about contributing anything like that, I suggest you open an issue with openhab-addons first and ask for opinions and advice there before you start implementing.

12

Modbus in principle never transfers a control command… It only transfers data words or bits… This data then may cause a device to do something, but mainly it doesn’t… There is no explicit command in modbus protocol, just a data written to a register maybe interpretet as a command by the bus slave device… And so obviously openhab also does… The channels from the binding just get updatet by a data transfer and obviously all three kinds (Com initiated by OH, Com initiated by other device, peer-to-peer/both can initiate the com) of data communication pattern are useable and used in OH bindings. And those channels then may or may not be connected to an item and the change of an item or the data in an item may or may not cause OH to do something. So e.g. a gpio input channel reports that it was switched on, this causes (in config standard) the connected item to change to ON and fires a item changed event. On this event or by evaluating the state of the item regularly a OH rule may or may not decide to command another item to change it’s state, which then thanks to the connected channel may send a turnon command to the MQTT broker for some other device… this other device then at whatever time reads that command from the broker and turns on (hopefully) and may even report that back to MQTT from where OH get’s an update to the channel and the items state… If I remember it right, the MQTT binding uses for this a “prediction” solution, in order to prevent the reporting back of turn on to fire an item changed event… It sends command on, then sets predicted to become on and if that happens within a given time doesn’t fire an item updated event… but will fire an item updated aand item changed event, if it gets a report back with item off (don’t nail me on that, it may also be a channel updated / channel changed event that is suppressed or fired here)… So I still see no greater design problem with doing that with a modbus slave binding to a modbus slave instance…
So lets try it… A gpio channel turns from of to ON, this causes a rule on OH to execute, saying that because of that a item which channel is connected with a register of the local modbus slave instance should be set to 70, which would e.g. make the inverter set it’s power generation limit to 70 percent once the inverter acting as modbus master reads that from the register. I really see no conceptual or design difference to what is hapening already, also with the modbus master binding:
A gpio input turns to ON, the channel causes an update and change to the connected item, this triggers a rule, that sends a command to an item setting it to 70, this item is connected with a channel of the modbus master binding, which knows adress and register of the inverter. On the next configured write cycle to that register the local modbus master instance will send the message to the Inverter in Modbus client mode with the new value… :slight_smile: Only difference I see, as a slave we are not able to control, when or if ever, the inverter will receive the data, but we know once it did read it, as the slave impl would need to send the answer to the request and can report that it did.

13

Seems my explanations on ‘mastership’ didn’t reach you so I’ll give up on that.

You seem to be locked into some special use case and I fail to follow your example. It’s confusing and I don’t see why one would want to be doing that and why this cannot be accomplished with OH being the Modbus master.
Then again, this is OSS. OH is what people made of it. So if you want to have that capability, code it and submit a PR.
Just as already suggested you should open an issue with openhab-addons before coding, tag it [modbus] so it reaches the right binding maintainer and ask if they would accept an addition that reverses master/slave or if there already have been discussions or anything in the works.

14

Am not locked into that special use case, but this is at least one, the use cases are a lot more… But after thinking about it more, it doesn’t even need a own binding… The Master binding is already enough to act as a slave… Not the most efficient way, but a easy doable… It just needs a slave process running whereever that listens on at least two ports… There OH can bind with the modbus master binding on one port and the other master can bind there also… Let’s call it a modbus broker…(as a modbus gateway is already defined as a device the acts as master on one side and as slave on the other in order to change the physical layer…). Think i can create something like that, where a integrated solution would be more performant… But hmm this one is more flexible, maybe