Interoperability with other OpenHAB instance


#1

I am trying to bring another existing OpenHAB instance in the mix, and I figured out that the easiest way to use the MQTT binding to connect HestiaPi’s MQTT server.

Everything is great, I just replicated TemperatureSetpoint, Temperature, even HeatingState.

However, I cannot fully integrate HeatingMode. The problem is that its state doesn’t get updated. If I change it the UI, it doesn’t get updated in the second OH, and the other way around.

HestiaPi’s OH thing is defined:

  Thing mqtt:topic:mosquitto:HeatingMode {
    Channels:
      Type string : string "HeatingMode" [
        commandTopic="hestia/local/cmnd/heatingmode",
        stateTopic="hestia/local/stat/heatingmode",
        retained=true
      ]
  }

and I see in the one-ui code that the UI suscribes to hestia/local/cmnd/heatingmode and publishes to hestia/local/stat/heatingmode

So I created the HeatingMode thing in the second OH the other way around, with commandTopic="hestia/local/stat/heatingmode" and stateTopic="hestia/local/cmnd/heatingmode"

But the HestiaPi OH HeatingMode thing does not update hestia/local/cmnd/heatingmode when its state changes

I have tried to add postCommand=true to HestiaPi OH HeatingMode thing without success.

Should I take a different approach?


#2

I’ve so thoroughly rewritten my configs I might lead you astray so take this with some caution. I don’t think I changed that aspect of the configs though.

On my main OH I have a Thing that uses the cmnd topic for both the commandTopic and the stateTopic. There are a couple of extra messages received (publish to the cmnd topic from the main OH which then arrives as a new message on the stateTopic) but it then stops because the Item stays the same state and I don’t have any Rules that do anything with received command on that Item.

Let me know if that works. If not I’ll dig into it deeper.

For reference, here is my main OH instance’s Channel config for HeatingMode

Which would be roughly equivalent to

Type: string: string "HeatingMode" [ commandTopic="hestia/local/cmnd/heatingmode", stateTopic="hestia/local/cmnd/heatingmode", retained=true]

I spend sooooo much time working with people who don’t get the Thing syntax right for MQTT that I don’t use .things files anymore. Based on my experiments, not doing so shaves almost half a minute off of the boot time for the HestiaPi.


#3

Sorry but it doesn’t seem to work :disappointed:

The UI in HestiaPi now changes with the main OH, but HestiaPi’s OH does not follow them

UI commands HestiaPi’s OH using the stat channel, but using the cmnd does not work

So storing configuration in JsonDB is faster than text files?

I am using JsonDB because I’d say I read in the documentation it was better to use the UI for things but text files for items, rules and sitemap.


#4

I’m not in a place where I can test it out but I’ll try to see what works when I get a chance. But I have changed the mode using that Thing before and it worked at some point or at least appeared to. But I pretty much never try to do stuff from the LCD so I can’t say whether or not it works when commanding the mode from the LCD like that. But it should.

When you change the mode using the LCD it publishes to the stat topic. The stat topic is subscribed to as a stateTopic on the Hestia OH so that will cause the binding to postUpdate the HeatingMode Item to the new state. The HeatingMode Rule triggers on change instead of command so it will trigger the Rule on the HestiaPi OH no problem.

The HeatingMode Thing on your main OH though would not have received the message because it’s subscribing to the cmnd topic for the stateTopic. So this is probably where it’s breaking down. You need to subscribe to the stat topic in order for your main OH instance to see the updates published from the LCD.

Now, let’s consider the other direction and you want to send the command to the Hestia from your main OH instance. You sendCommand to the HeatingMode Item on your main OH instance which then goes to the binding. The binding publishes the command to the stat topic (topic linked to commandTopic). Your HestiaPi OH will see that message since it subscribes to the stat topic and it’s HeatingMode Item will change state which will trigger the Rule and the heating will turn on. So far so good.

But the LCD won’t change because the LCD doesn’t subscribe to the stat topic, it subscribes to the cmnd topic.

I’ve not looked at this thoroughly yet but I think the following will work. On your main OH instance, configure your Thing exactly the same as the HestaiPi’s Thing: commandTopic to the cmnd and statetopic to stat. Then we will assume that the One UI will publish the result of it processing the command to the stat topic for us. So the flow will be:

  • Main OH publishes to cmnd topic
  • One UI processes message, changes its state and publishes the change in state to the stat topic
  • HestiaPi OH receives the message from the stat topic, changes the state of HeatingMode which kicks off the Rules to activate the new mode.

One thing to remember is HestiaPi has OH deployed to a RPi 0 which is far below the minimum recommended specifications for running OH. That’s why it takes 20-30 minutes for the HestiaPi to book and become usable. Parsing and converting the text configurations is processor intensive and the RPi 0 only has one very low powered core. So it takes a good deal of time to parse the text configs and almost half of that 25-30 minutes is loading and parsing the .rules file alone. It takes a lot less work for the JSONDB files because it is almost just a matter of mapping the files into memory and it’s done, no parsing and very little syntax checking required.

Given this extreme amount of time required to boot, it’s worth the loss of some of the convenience (for developers) and features (that HestiaPi isn’t using anyway) that cause the recommendation for using text configs for everything but Things for general OH not the best choice for HestiaPi. So I’ve been working to move everything (including Rules) to JSONDB and so far I’m seeing very good results. The time from the blank white screen on the LCD to a working HestiaPi is almost exactly 10 minutes for me right now. It could be faster but there is no working System started Rule trigger for JSONDB Rules right now that I can use to trigger the initialization Rule to run. If I had that I could shave another minute or two off the boot I think as we don’t have to wait around for the load to drop before allowing the rule to be loaded and run the initialization.

Another advantage JSONDB everything has for users is you can see and change just about anything you would want to through PaperUI. Imagine being able to change the rule that determines when to turn on/off the heater to use a hysteresis in the calculation without needing to edit the files, and it takes effect immediately without a 10 minute wait while OH parses and loads the new .rules file. That’s what I’m trying to achieve. And I’m very close. There are a couple of small quirks with how the LCD is behaving I want to iron out and I want to add a check to not allow Cooling Boost mode to turn on when it’s already Heating and visa versa.

Some things though can only be done in text configs, including sitemaps. The Items linked to the GPIO binding also must be in .items files.

Anyone who wants to alpha test what I’ve done let me know and I’ll see if I can get it to you. It will require a bit of work to install though because you will need to stop OH, remove some files and copy some more file to another folder.


#5

This is not happening right now. One UI just updates the interface but it does not forward the state change back to the stat topic

I don’t have much time, but I can try

I am integrating ANAVI Thermometer, so I need to touch the configuration. I also want to clean it up, so if your JSONDB rewrite is faster, I can use it as start point

I didn’t expect that text files introduced that much overhead :thinking:


#6

I’m still tracing down a bug on reboots where the screen doesn’t reflect the state I want it to (i.e. if the Fan happened to be ON before restarting but Heating or Cooling are also ON, I want the LCD to default to Heating or Cooling, not Fan when it comes up. Beyond that it seems to be working fairly well.

How familiar are you with how OH works and the JSONDB configs? If I drop a zipped up backup into Google Drive would you know what to do with it, or do I need to write up some docs? There are changes to pretty much everything, sitemap, items, rules, etc. And I depend on some new features in OH 2.5.3 so you will need to upgrade your OH as well.

If you don’t have a lot of time I completely understand if this is too much to look at right now. But if you are planning on cleaning up the configs anyway, this might actually save you some time in the long run.

OK, in that case in order to have the UI update and the Rule triggered, you need to publish to both topics from your main OH. To do that you need one Channel with the stat Channel configured for the commandTopic and another Channel with the cmd topic configured for the commandTopic. Have one of them subscribed to the stat topic as well. Then link both Channels to the same Item but link the Channel that is not subscribed to the stat topic second and set up a follow profile. This will forward any command you send to both Channels and therefore to both topics. That should update the LCD and trigger the Rule.

Let me know if you need help with any of that.


#7

I know how to place the files under /etc/openhab2. I am not so sure about the ones at /var/lib/openhab2/jsondb. I located the things at org.eclipse.smarthome.core.thing.Thing.json but I am not sure if I need to do anything more than dropping the files and restarting the service.

Sure, I am willing to help and try it. It is only about settings expectations. As an example, I was able to reply to your message after 4 days :sweat:

Is this still the case with the new configs? If not, I will wait