I am getting desperate at trying to get two instances of OpenHAB integrated. For now, only one has a physical Z-Wave stick, while the other will get it as soon as I get this running (if I ever get). My basic setup is:
Machine MAIN that currently holds the Basic UI and shows the sitemap of my home. It will get a z-wave stick to control devices in it’s surrounding, if I get this working.
Machine PI1 that currently has a z-wave stick attached and manages the z-wave devices it can reach
The reason for this setup is, that I have devices that I cannot reach from the PI1 machine, and therefore I want a second machine to take them over and make my network more reliable.
I’ve tried to follow the documentation on MQTT, since @Kai mentioned somewhere else, that MQTT would be the way to go to have two or more OpenHAB instances connected. However, I’m ending up in an infinite loop on both machines when looking at the logs, whatever I do. My current configuration looks as follows:
mqtt-eventbus.conf on MAIN:
broker=mosquitto
commandPublishTopic=/main/out/${item}/command
stateSubscribeTopic=/pi1/out/${item}/state
assuming that the commands are issued via rules or Basic UI on that machine and that states chaining on PI1 are reflected then back in Basic UI.
mqtt-eventbus.conf on PI1:
broker=mosquitto
statePublishTopic=/pi1/out/${item}/state
commandSubscribeTopic=/main/out/${item}/command
However, this as all other tries I’ve done (like enabling all four publish/subscribe options) end up in loops like this (log from Pi1 but looks similar on MAIN):
2017-06-24 00:37:11.880 [ItemStateChangedEvent ] - LIGHT_EG_Arbeitszimmer changed from ON to OFF
2017-06-24 00:37:11.894 [ItemStateChangedEvent ] - LIGHT_EG_Arbeitszimmer changed from OFF to ON
2017-06-24 00:37:11.911 [ItemStateChangedEvent ] - LIGHT_EG_Arbeitszimmer changed from ON to OFF
2017-06-24 00:37:12.184 [ItemStateChangedEvent ] - LIGHT_EG_Arbeitszimmer changed from OFF to ON
2017-06-24 00:37:12.454 [ItemStateChangedEvent ] - LIGHT_EG_Arbeitszimmer changed from ON to OFF
2017-06-24 00:37:12.465 [ItemStateChangedEvent ] - LIGHT_EG_Arbeitszimmer changed from OFF to ON
2017-06-24 00:37:12.474 [ItemStateChangedEvent ] - LIGHT_EG_Arbeitszimmer changed from ON to OFF
2017-06-24 00:37:12.776 [ItemStateChangedEvent ] - LIGHT_EG_Arbeitszimmer changed from OFF to ON
2017-06-24 00:37:13.028 [ItemStateChangedEvent ] - LIGHT_EG_Arbeitszimmer changed from ON to OFF
2017-06-24 00:37:13.034 [ItemStateChangedEvent ] - LIGHT_EG_Arbeitszimmer changed from OFF to ON
2017-06-24 00:37:13.050 [ItemStateChangedEvent ] - LIGHT_EG_Arbeitszimmer changed from ON to OFF
2017-06-24 00:37:13.357 [ItemStateChangedEvent ] - LIGHT_EG_Arbeitszimmer changed from OFF to ON
2017-06-24 00:37:13.597 [ItemStateChangedEvent ] - LIGHT_EG_Arbeitszimmer changed from ON to OFF
2017-06-24 00:37:13.621 [ItemStateChangedEvent ] - LIGHT_EG_Arbeitszimmer changed from OFF to ON
2017-06-24 00:37:13.667 [ItemStateChangedEvent ] - LIGHT_EG_Arbeitszimmer changed from ON to OFF
2017-06-24 00:37:13.900 [ItemStateChangedEvent ] - LIGHT_EG_Arbeitszimmer changed from OFF to ON
I kept only one light actor to make reading easier. I would be very thankful if somebody could either enlighten me what I’m doing wrong or just tell me that it’s impossible to have two OpenHAB instances running that way. Thanks a lot in advance!
I had a similar set up until a few months ago when my second RPi died from a lightning strike. I was connecting an main OH1 server with an OH2 server (for Sonos and general experimentation). It worked fine although I do remember I had some infinite loop issues until I had it configured correctly.
However, I don’t see any obvious problem with your configuration. Is there a possibility that you have rules that are being triggered from the state or command changes? You also might want to enable trace logging in the MQTT transport and binding bundles to see what’s happening at the message broker level. You could also write a small program to listen to the MQTT topics directly to see what messages are being exchanged.
thanks for your reply. Good that you don’t see an obvious problem and that you had it running. That keeps me positive to get it up. I’ll have to investigate more, to see what the problem is.
Yes, I ran an OH1 instance with roughly that number of items integrated with an OH2 instance with around 50+ items using the MQTT eventbus. I feel using the eventbus is an advanced technique. You should be willing and able to turn on low level debug logging to diagnose issues like you are having. You also must think carefully about how events are flowing between the systems. For example, you shouldn’t set up both servers to publish state events for the same item. This is a common cause of infinite loops.
How to avoid both servers to publish state events for the same item?
For example:
I connect my Home-OH with my Work-OH so I can toggle the lights at work even if I’m at home.
Isn’t this a real-world scenario the eventbus is made for?
If Home-OH only publishes commands to Work-OH for the work light items and Work-OH only publishes state updates for the work lights then there shouldn’t be a loop. More generally, a typical configuration is that one server is a “master” (only publishes commands and only subscribes to state updates on the MQTT bus) and the other is a “slave” (only receives commands and only publishes state updates on the bus). If one is very careful, this can be done at the item level, but usually it’s easiest to defined the master/slave relationship at the server level.
Home-OH should be able to toggle the light and Work-OH, too.
Depending, if I’m connected to the one or the other sitemap.
Would you say, this is a wrong systemdesign for the use of mqtt-eventbus?
Not necessarily. Let’s say you send a command to the light from Work-OH. The Work-OH server does not publish commands so no MQTT message is sent to Home-OH. However, the resulting state update is published from Work-OH and is received by the Home-OH subscription. Home-OH updates it’s local state based on the MQTT message. However, it doesn’t publish state events to MQTT so there’s no loop. If you send the light command from Home-OH, the Home_OH server publishes the command to MQTT and updates it’s local state (state not published). The Work-OH server receives and executes the command. The Work-OH item state update is published to Home-OH, but this won’t cause a loop (although it is redundant).
After having now three instances set up and working together, I can confirm your suggestion worked.
I have to do that, since I have too many Z-Wave devices and one Aeotec stick gets fairly laggy on performing commands when having more than 25-30 devices registered to it, so I have now one per floor and for the garage and it works amazing.
@mashborn, have you connected one of the Items directly to your physical Thing by adding its channel to the Item you use for the MQTT connection? If so, could you please post an example, as I am trying to this as well, and I’m failing miserably.
