OmniLinkBridge to integrate Home Assistant, SmartThings, Node-RED

[pete_c]

There is your issue.  Remove your MQTT references to start with a blank slate if you want. 
 
The OmniLinkBridge plug only talks MQTT.  
 
Enabling the OmniLinkBridge on once and off will generate the error messages you posted above relating to the high/low temperature stuff.
 
I see you are using Hassio.  Here started initially using Hassio and went to Ryan's suggested methodology of using Docker for HA and the OmniLinkBridge.
 
I did originally start here with Hassio and defaults; then switched to using Docker and made my life a bit easier.
 
I have added many custom WiFi devices (using custom Espurna / Tasmota firmware), Alexa devices, et al to my production HA build.  It is the same with just HA running in docker.
 
The configuration files are easier to adjust for me this way.
 
I have not added my MQTT stuff yet to the new build which is this in the "production" build.

 

[123]

Not sure how to do this with Hass.io.

 
The configuration directory for Hass.io is located in:
 

/config 
 
So when in the terminal window, just
 

cd /config 
then run the grep command I suggested. 
 
I'm making an assumption that the minimal version of Linux used by Hass.io includes grep.

 

[grantlewis]

Well, today I learned that you can traverse folders in a hass.io terminal session.  :blush:
 
Unfortunately the grep command just hangs for me.
 
 

debug1: permanently_set_uid: 0/0
core-ssh:~# ls
core-ssh:~# cd /config
core-ssh:/config# grep -rni "climate.lower_tstat"
^C
core-ssh:/config# 

 

[123]

Unfortunately the grep command just hangs for me.

 
I'd advise to wait at least a minute before giving up but maybe you already did that.
 
Rather than chase down why grep is misbehaving on Hass.io, let me ask you a question:
 
How did you go about confirming neither /config/configuration.yaml or /config/.storage/core.entity_registry contained any references to a climate component, such as climate.lower_tstat or climate.upper_tstat?

 

[grantlewis]

I just loaded the file into Visual Studio Code and searched for climate. No results.

 

[123]

I just loaded the file into Visual Studio Code and searched for climate. No results.

 
"the file"
 
Which one? One or both? 
 
I'm having trouble understanding how you inspected them when, a few posts ago,  you appear to have not been aware Hass.io's config files are in /config. Anyway, if you are certain neither of the two files contains any reference to climate components, yet two such entities appear in the States page, then we'll just have to chalk it up to magic.
 
Take Pete's advice and re-install the entire system. Should the two thermostats appear again then we know it's not just magic but a miracle.
 
Good luck!

 

[pete_c]

This is just a post relating to the installation of Docker and Home Assistant on an ARM based Ubuntu server.  I have miniaturized my server to fit inside of the OmniPro 2 media can.
 
Going to move this to a blog such that it doesn't get lost.
 
Docker on aarch64
 
1 - Install prerequesites:

sudo apt install -y apt-transport-hxxps ca-certificates curl gnupg2 software-properties-common
 
2 - install docker gpg
 
curl -fsSL hxxps://download.docker.com/linux/debian/gpg | sudo apt-key add -
 
3 - install docker repository for arm64

sudo add-apt-repository "deb [arch=arm64] hxxps://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"

4 - update
 
sudo update
 
5 - install docker-ce

sudo apt-get install -y docker-ce
 
Home Assistant on aarch64

1 - docker pull homeassistant/aarch64-homeassistant
 
2 - create an homeassistant config directory
 
mkdir -p /opt/home-assistant/config
 
3 - install HA configuration and update if necessary
 
docker run -d --name="home-assistant" -v /opt/home-assistant/config:/config -v /etc/localtime:/etc/localtime:ro --net=host --restart unless-stopped homeassistant/aarch64-homeassistant:latest
 

 

[123]

There's one more source for the two thermostats. However, it's so specific that, if you had used it, you would've remembered it.
 
It involves MQTT Discovery but used in a very specific way.
https://www.home-assistant.io/docs/mqtt/discovery/
 
If you publish an entity's discovery topic without specifying a unique_id, the entity will not be registered in core.entity_registry. Home Assistant will "re-discover" the entity, via the entity's discovery topic, each time it restarts. However, to achieve this, the discovery topic's message must be published as a retained message. Otherwise, the broker doesn't retain the topic's message and, when Home Assistant restarts and re-subscribes to the entity's discovery topic it'll receive nothing (i.e. no entity will be discovered).
 
Here's a simple example involving the discovery of a binary_sensor:
 
1. This binary_sensor will be discovered and registered in core.entity_registry.
Although retain=false, after restarting Home Assistant the binary_sensor will be defined because it is registered.

pic: homeassistant/binary_sensor/garden/config
Payload (retain=false): {"name": "garden", "device_class": "motion", "unique_id":"ABC123"}

2. This binary_sensor will be discovered but not registered in core.entity_registry.
Because retain=false, Home Assistant will fail to discover it after a restart until the message (payload) is re-published.

Topic: homeassistant/binary_sensor/garden/config
Payload (retain=false): {"name": "garden", "device_class": "motion"}
3. This binary_sensor will discovered but not registered in core.entity_registry.
Because retain=true, after restarting Home Assistant the binary_sensor will be re-discovered because its discovery topic's message is retained by the broker.

Topic: homeassistant/binary_sensor/garden/config
Payload (retain=true): {"name": "garden", "device_class": "motion"}
 
So if you ever did case #3, it would explain why Home Assistant is still discovering the two thermostats.

There are two easy ways to confirm if this is what's happening. Try either one of these:

1. Temporarily disable MQTT Discovery in the configuration file. If it's already disabled (that's its default state) then none of this applies to you and those two thermostats are still being found magically.

2. Use an MQTT client, like MQTT Explorer, to view all of the broker's topics and see if there are discovery topics for the two thermostats (with retained messages).
https://mqtt-explorer.com/

 

[pete_c]

Here on the new computer with most current version of HA and OmniLinkBridge do not see log errors any more related to the high low temps which works for me.  IE: enabled MQTT yesterday....
 

 
Suggestion to Grant...put all of your stuff on one box....my preference here is Ubuntu...you mentioned running OmniLinkBridge in Windows earlier...it is way easier to manage this stuff if it is all on one box....IE: an RPi maybe. Here currently using a quad core Pine64 2Gb computer with Armbian Ubuntu 18.04...and switching this to a smaller box (TV box) which is an Octocore Arm with 3Gb of RAM running Armbian Ubuntu 18.04. (5 watts of power utilized to run this box).
 
1 - OmniLinkBridge - run this in docker as documented - it is easy to configure and INI file resides on one directory and is easy to adjust
2 - MQTT - just do an apt install mosquitto and that is it
3 - Home Assistant - run this in docker and use HA instead of HASSIO.
 
You can also run MQTT in docker such that when tinkering you can do:
1 - docker stop home-assistant
2 - docker stop omnilinkbridge
3 - docker stop mosquitto
 
Also here on the same box running Mono and Homeseer 3 (with MQTT plugin for interaction with HA and new firmware updated WiFi devices).
 

 
You have also mentioned that your real issues / concerns relate to the HA Lutron plugin.  I do not utilize Lutron here but tell us some more about your issues here.
 
 
Learning the Lovelace-UI cards this morning...adding Alexa and Squeezebox players ....automations and scripts...

 

[grantlewis]

"the file"
 
Which one? One or both? 

 
Must've angered the 'net gods -- they ate yesterday's reply.
 
Both files. I customarily browse / edit HA files via SMB rather than via SSH.

 

[grantlewis]

Suggestion to Grant...put all of your stuff on one box....

 
I do appreciate the continued insight and recommendations, Pete. I may attempt something like this eventually but dammit... I'd really rather just fix the bug rather than rebuild the whole house, y'know? My move to Virtual Box was FROM RPi3 because at the time I suspected that the Pi hardware might have been the issue. Since the very same problem continues on Virtual Box, I know that's not the case. And many months ago I ran Hassbian... so everything old is new again.  :wacko:
 
I have an HP Pavilion with Ubuntu on it not serving any practical purpose. But that computer is in my networking closet, and if I were to use it for HA, I'd have to plug my Aeotec USB into it there -- and that location isn't optimal in terms of Zwave signal. 
 
Thanks to Virtual Box at least I have an easy way to revert to a fully working system while exploring other options. Now all I need is no responsibilities or interruptions for about 10 days...

 

[pete_c]

Yes here run VB's of Windows (server) and Windows (W7) on main automation server running Ubuntu 18.04 for Microsoft SAPI mostly.
 
Using an RPi2 with a Z-Wave dot me card (or shim) POE connected in the attic of a two story home taking ZWave to ethernet using ser2net extending the ZWave footprint.
 
The ZWave network is replicated to an HAI VRCOP in the basement and a Samsung Smartthings on the main floor of a two story home.
 
Over the years been tinkering with a mini automation server which originally was for use with Homeseer 3 Lite (Zee2) initially running it on an RPi, then an XiS Xi5A mini cube computer and most recently running it on a Pine64 2Gb computer. 
 
Today the Pine64 2Gb computer runs Homeseer 3 (lite), HA, Mosquitto, Node Red, OmniBridge Link and it is hardly working.
 
Next is to downsize it some more moving the concocation to an Octocore Arm with 3Gb of RAM which utilizes 5 watts and can be POE connected putting it anywhere in the house and is faster than the Pine64 2 Gb computer which is faster than the RPi3 computer.

 

[123]

Both files. I customarily browse / edit HA files via SMB rather than via SSH.

 
OK, then I'm led to believe that my hunch is correct. As explained in my previous post, your situation is case #3. The thermostats are being found by MQTT Discovery. The two thermostats have 'discovery topics' whose information was published to the broker as retained messages. 
 
The first post in this thread provides installation instructions for the OmniLInkBridge. It specifies setting 'discovery: true' for MQTT and 'discovery_topic: homeassistant'. If you still have those two lines in your configuration file, Home Assistant will use MQTT Discovery to find MQTT-based devices.
 
OmniLinkBridge creates discovery topics so that Home Assistant can find them (via MQTT Discovery). I browsed its source code and this line publishes the discovery topic for a thermostat.
https://github.com/excaliburpartners/OmniLinkBridge/blob/a9c52b433f1335d638b9d8f9ff6398c35e9d2f8d/OmniLinkBridge/Modules/MQTTModule.cs#L404
 

MqttClient.PublishAsync($"{Global.mqtt_discovery_prefix}/climate/{Global.mqtt_prefix}/thermostat{i.ToString()}/config",
                    JsonConvert.SerializeObject(thermostat.ToConfig()), MqttQualityOfServiceLevel.AtMostOnce, true);

 
The important thing to take note here is the final 'true' parameter. It means retain=true therefore the message will be retained by the broker. As a result, the moment any instance of Home Assistant, employing MQTT Discovery, connects to the broker, it will find your two thermostats climate.lower_tstat and climate.upper_tstat. Magic!
 
As I stated in my previous message, you can easily confirm all of this by either temporarily disabling MQTT Discovery (set 'discover: false' then restart Home Assistant; the two thermostats should disappear from the States page) or just examine the broker's topics using an MQTT client. MQTT Explorer does a good job of displaying all topics in a tree-view and identifying the ones containing retained messages. It also lets you easily delete retained messages.

 

[arakasi55]

Firstly, thanks to those working on solutions like this to keep the OPII up with modern technology!

I'm currently running my OPII along with HomeSeer and the HomeBridge middleware so that I have Alexa and HomeKit integration and it's been working really well. I've heard and seen good things with HomeAssistant so thought I'd have a play with that too, but have found that the HomeKit integration is still a bit behind HomeBridge - at least for now.

One question I have is that I have the outputs on my OPII controlling my irrigation but for some reason, OmniLinkBridge/MQTT are publishing the outputs as lights to HomeAssistant. Is there anyway I can change this, even to a switch? It seems with the HomeKit integration you can change a switch to different settings, but not lights.

 

[pete_c]

Is there anyway I can change this, even to a switch?
 
I think you can modify the Home Assistant default MQTT stuff by putting the device in the configuration.yaml file.
 
I have not done this with any OmniPro panel MQTT devices.
 
A couple of my outputs here are defined as buttons which are seen as Home Assistant switches.
 
You can do this also with the Homeseer 3 mcsMQTT.  IE: here utilize the HS3 Omni Plugin, mcsMQTT plugin and Home Assistant / OmniLinkBridge plugin.
 
These all play nice together.