OmniLinkBridge to integrate Home Assistant, SmartThings, Node-RED

grantlewis

The OmniLinkBridge doesnt talk to Home Assistant directly. It only publishes to MQTT. Using an MQTT client you can subscribe to omnilink/status which will show you online or offline. Thats what triggers Home Assistant to know if the device is unavailable.

At this point Im not sure which side the issue is on. I havent had a chance to test 0.81.6 to see if there is an issue with MQTT device discovery due to that patch O mentioned above
 
rsw686
 
I'd be willing to bet it's got something to do with MQTT. But geez: what a nasty bug (if it really is a bug I've discovered).
 
Thank you Ryan...forgot to run:
 
docker run -d --name="home-assistant" -v /opt/home-assistant/config:/config -v /etc/localtime:/etc/localtime:ro --net=host --restart unless-stopped homeassistant/home-assistant:0.81.4
 
First time ran it (without version number) it updated to latest version which I didn't want to run.
 
Looking and attempting here to integrate my new 1-Wire hub currently utilizing DS18S20 1-wire sensors and testing JSON lines utilizing the console in Tasmota.
 
Getting zero values for temperature though.  Anyone else try this yet?
 
Here is the console message I see for three 1-wire DS18S20 sensors connected to one SonOff WiFi.
 
11:50:34 MQT: /1Wire/SENSOR = {"Time":"2018-11-06T11:50:34", "DS18x20":{"DS1":{"Type":"DS18S20", "Address":"10AE56130008007B", "Temperature":69.7}, "DS2":{"Type":"DS18S20", "Address":"10A52F47000800CB", "Temperature":71.4}, "DS3":{"Type":"DS18B20", "Address":"280D7E5B04000049", "Temperature":81.8}}, "TempUnit":"F"}
 
Here is a template that I am using.  I have changed the JSON values a few times with no results yet.
 
# Weather prediction
sensor:
  - platform: yr
  - platform: mqtt
    state_topic: '/1Wire/SENSOR'
    name: 'Hallway'
    unit_of_measurement: '°F'
    value_template: '{{ value_json ["DS18x20"]["DS1"]["DS18S20"]["Temperature"] }}'
    or
    value_template: '{{ value_json ["DS1"]["DS18S20"]["Temperature"] }}'
 
# value_template: '{{ value_json["DS18x20:DS1"]["Temperature"] }}'
#

11:50:34 MQT: /1Wire/SENSOR = {"Time":"2018-11-06T11:50:34", "DS18x20":{"DS1":{"Type":"DS18S20", "Address":"10AE56130008007B", "Temperature":69.7}, "DS2":{"Type":"DS18S20", "Address":"10A52F47000800CB", "Temperature":71.4}, "DS3":{"Type":"DS18B20", "Address":"280D7E5B04000049", "Temperature":81.8}}, "TempUnit":"F"}

11:55:35 MQT: /1Wire/SENSOR = {"Time":"2018-11-06T11:55:35", "DS18x20":{"DS1":{"Type":"DS18S20", "Address":"10AE56130008007B", "Temperature":69.5}, "DS2":{"Type":"DS18S20", "Address":"10A52F47000800CB", "Temperature":71.3}, "DS3":{"Type":"DS18B20", "Address":"280D7E5B04000049", "Temperature":81.6}}, "TempUnit":"F"}

Got it changing the JSON template to:

# Weather prediction
sensor:
- platform: yr
- platform: mqtt
state_topic: '/1Wire/SENSOR'
name: 'Hallway'
unit_of_measurement: '°F'
value_template: '{{ value_json ["DS18x20"]["DS1"]["Temperature"] }}'


11:50:34 MQT: /1Wire/SENSOR = {"Time":"2018-11-06T11:50:34", "DS18x20":{"DS1":{"Type":"DS18S20", "Address":"10AE56130008007B", "Temperature":69.7},
 
 
pete_c
 
I haven't experienced that in particular, but I did recently install a Sonoff S31 flashed with Tasmota (6.2.1 I believe) and had difficulty pulling power readings from it. The explanation I found was over my head but it had something to do with data points being mis-aligned in Tasmota. So although the device was properly reporting, the data was mangled on its way out. Maybe something similar in your case?
 
I didn't need to retrieve precise measurements -- only that the Sonoff was pulling current -- and so was able to devise a work around. I'm now running 6.3.0 on that device. Since my workaround is still doing what I need it to do, I haven't checked to see if the new firmware fixed the data problem or not.
 
Thank you Grant.  Slowly here have been modding SonOff devices. 
 
Way back with a previous Tasmota firmware 4-5X versions I could not see multple DS18x20s 1-wire chips. Still using old 1990's AAG 1-wire temperature sensors here.
 
Above it was just looking at the console and picking the right variables for the JSON template.  IE: editing the yaml file and just restarting HA.
 
There is a bit of interplay here between the OmniStat, Omni combo sensors and now the 1-wire sensors using HA.
 
I have replicated (a bit over kill) the Omni Pro wired GDO stuff with a combo SonOff (Tasmota) firmware two sensor (one door), button and temperature sensor.  Works well in the garage.  Timing of status is the same speed as what I am getting from the OmniPro 2 panel.
 
Have two SonOff devices configured with ESPurna which I sort of like better than Tasmota.  The interface let's you configure a static IP address, DNS, NTP et al.
 
Hass.io 0.81.2 had been doing pretty well for several days since my prior problems, so after backing everything up, I decided to try 0.81.6 again. After applying the upgrade, all of the HA controls for OmniLinkBridge entities were reporting "Unavailable." So I immediately restored 0.81.2 from backup. When the restore was complete and HA had finished rebooting, even the HA controls themselves were missing -- no "Unavailable," no nothing. So I restarted. While the reboot was taking place, I did a net stop / start of the OmniLinkBridge. When that reboot was complete, there were still no HA controls or OmniLinkBridge entitles. 
 
Another thing I noticed: whereas earlier I was seeing entries in the log warning "You are using a custom component for climate.mqtt which has not been tested by Home Assistant," that warning is not in the logs now even though the contents of the HA custom_components folder had not changed.  
 
I completely shut down both the RPi3 running HA and the OmniLinkBridge Win10 machine. As the RPi3 was shutting down, I deleted the home-assistant_v2.db file. I waited for 2-3 minutes and then rebooted both machines. When the Win10 machine came back up, I ensured that OmniLinkBridge was running. When HA finished initializing, I was greeted with all of my usual HA controls, but all of the controls for OmniLinkBridge were "Unavailable." On a whim I took a look at the Hassi.o Mosquitto broker panel and saw several errors there. I restarted the broker. At that point both the HA controls AND the OmniLinkBridge entities came back to life. I've given things a pretty thorough look-over and believe that everything's back to normal on 0.81.2.
 
So what I discovered:
= = = = = = = = = =
  • 0.81.6 is toxic for my setup. I'm avoiding it for the time being.
  • To get back to a working configuration after a restore, I need to completely shut down the hardware running HA and OmniLinkBridge. Restarting doesn't seem to do the job.
  • Deleteing the home-assistant_v2.db file might be necessary.
  • After rebooting the mosquitto client needs to be restarted.
 
Thank you grantlewis for the FYI.  Updated here to V0.82.0    
 
1    ~# docker stop home-assistant
home-assistant    
2    ~# docker rm home-assistant
home-assistant    
3    /opt# docker run -d --name="home-assistant" -v /opt/home-assistant/config:/config -v /etc/localtime:/etc/localtime:ro --net=host --restart unless-stopped homeassistant/home-assistant:0.82.0    
Home Assistant 0.82.0  
 


 
/opt# docker image listREPOSITORY                     TAG                 IMAGE ID            CREATED             SIZE
 
homeassistant/home-assistant   0.82.0              d85afe2e3407        4 days ago      2.2GB
homeassistant/home-assistant   0.81.4              e4ce187f1b99        12 days ago         1.78GB
omnilink-bridge                latest              16f65f94f78f        2 weeks ago 666MB
mono                           latest              f10d48e24cfd        4 weeks ago       605MB
nodered/node-red-docker        v8                  d7b7ac4d8df7        8 weeks ago         720MB
 
Have been seeing one issue with one HAI Outside temperature sensor here. 
 
Eventually the temperature sensor comes up but it lags behind the indoor combo temperature humidity sensor. 
 
It's an old HAI Outdoor Temperature sensor and never has been too accurate.
 
I only see this with OmniLink and not with OmniTouch screens.  
 
HHAIOutdoorSensor.jpg  
 
I am adding aux temperature and humidity sensors via 2 modded Sonoff WiFi basic modules with now DS18B20's and DHT22's running Tasmota Mosquitto firmware.
 
garage.jpg
bbasement.jpg
hhallway.jpg  
 
Very easy and plug n play.      
 
@Ryan,  
 
Wanting to add HAI Omni Pro system variables here:  
 
# mqtt_discovery = id=5;device_class=battery
# specify a range of numbers like 1,2,3,5-10
# device_class must be battery, door, garage_door, gas, moisture, motion, problem, smoke, or window
# mqtt_discovery_override_zone = id=5;device_class=garage_door
# mqtt_discovery_ignore_zones =
# mqtt_discovery_ignore_units =  
 
Got ignore zones and units working well.  
 
I have a special status variable in very old software which changes to phone off or on hook, alarm enabled or not, et al.  
 
It is not seen in PCA but it is in the SDK. 
 
The variable is known as special status.  I use this variable sometimes to trigger events.
 
For special status see this HAI System CTRL 2  
 
Always changes depending on what happens with the panel.   
 
IE: Phone Line On Hook  or Phone Line Off Hook if I pick up the phone.

This device tracks special panel status conditions.

These conditions have status (string) values and numerical values just as the Security Status does.
       
special status.jpg
 
SDK shows:
 
 
 
 
Leviton fixed the camera pop up trigger with most current firmware. 

This is used with a doorbell ring and Omnitouch screens.

Originally Leviton had fat fingered out this function, here opened a ticket and spoke to a Leviton HAI person validating that the function no longer worked. They fixed it but never told me about it such that when I updated the firmware it just magically started to work again.

Utilize the phone on and off hook stuff with a W2Call box which monitoring incoming and outgoing calls and does stuff like pick up and drop calls well and dials out with custom CIDs if need be. Doorbell ring can dial out a custom CID like "doorbell_Ring" to any number out internally or outside.
 
Ryan,
 
Thanks so much for developing this solution. I have been looking for a replacement for Haiku and just haven't been happy with anything. 
 
I am currently using Homeseer along with Alexa. But I still mainly rely on Haiku.
 
I am installing the Bridge now and will be connecting to it with Node-red. 
 
I am really looking forward to playing with it.
 
Joe
 
Ok, I do have a questions now.
 
In the .INI file, what should the MySQL connection string look like for Linux? 

Also, can you please subscribe the MQTT topics,etc. a little more?

I am not quite sure what to subscribe to.

Thanks

Joe
 
Joe,

The mySQL connection is only needed if you would like additional logging. I actually haven't tested it on linux with mono. However the mono project has information on setting up ODBC.

For MQTT you need a broker installed like Mosquitto. For OmniLink Bridge the bare minimal configuration would be to define he controller_address, controller_key1, controller_key2, mqtt_server and set mqtt_enabled to yes. The communication between the components looks like this:
Home Assistant <=MQTT Protocol=> Mosquitto <=MQTT Protocol=> OmniLink Bridge <=OmniLinkII Protocol=> OmniPro Controller

On the Home Assistant side you would add the following you your configuration.yaml
Code: 
mqtt:
    broker: localhost (or host/ip)
    discovery: true
    discovery_prefix: homeassistant
 
You must log in or register to reply here.

Similar threads

A
Home Assistant OmniLinkBridge
Replies
5
Views
928
pete_c
pete_c
pete_c
Pete's Blog Migration of Home Assistant and Homeseer 4 to new hardware-OS
Replies
0
Views
834
pete_c
pete_c
Back
Top