OmniLinkBridge to integrate Home Assistant, SmartThings, Node-RED

[arakasi55]

Sorry, to clarify, that image from Homeseer is using the HAI plug in, not MQTT

 

[pete_c]

Understood.
 
Just wanted to know the values from the thermostat. 
 
So -
 
1 - Omni Panel ==> Homeseer Omni Plugin ==> temperature values are fine and in Centigrade
 
2 - Omni Panel ==> OmniLinkBridge (MQTT) ==> Omnilink MQTT ==> values are fine and in Centigrade
 
3 - Omni Panel ==> OmniLinkBridge (MQTT) ==> HA Climate ==> values are in Centigrade in HA except for LoveLace UI card.

 

[arakasi55]

Almost. HA temps are all in Fahrenheit. Omni is sending C, MQTT sees C, by time it reaches HA its in F.

The code I linked to on Ryans GitHub under thermostat has to be the culprit, but I cannot find where that code resides

1 - Omni Panel ==> Homeseer Omni Plugin ==> temperature values are fine and in Centigrade

2 - Omni Panel ==> OmniLinkBridge (MQTT) ==> Omnilink MQTT ==> values are fine and in Centigrade

3 - Omni Panel ==> OmniLinkBridge (MQTT) ==> HA Climate ==> values are in Fahrenheit

 

[pete_c]

Here only have the longitude, latitude, time zone, elevation with unit system at imperial and configuration.yaml file.
homeassistant:

  # Name of the location where Home Assistant is running
  name: ICS-Home
  # Location required to calculate the time the sun rises and sets
  latitude: 41.....
  longitude: -87........
  # Impacts weather/sunrise data (altitude above sea level in meters)
  elevation: 250.8
  # metric for Metric, imperial for Imperial
  unit_system: imperial
  # Pick yours from here: http://en.wikipedia.org/wiki/List_of_tz_database_time$
  time_zone: America/Chicago
  # Customization file
  customize: !include customize.yaml
 
 
 
Is your set to metric?  I wonder how it makes a difference between F and C?

 

[arakasi55]

Yes, mine is set to metric with temps set to C

homeassistant:
# Name of the location where Home Assistant is running
name: Home
# Location required to calculate the time the sun rises and sets
latitude: -37.....
longitude: 144.....
temperature_unit: C
# Impacts weather/sunrise data (altitude above sea level in meters)
elevation: 0
# metric for Metric, imperial for Imperial
unit_system: metric
# Pick yours from here: http://en.wikipedia.org/wiki/List_of_tz_database_time_zones
time_zone: Australia/Melbourne
# Customization file
customize: !include customize.yaml

 

[pete_c]

Never have used
 
temperature_unit:C
 
under the location in the configuration yaml file.   Remove it.  I don't know if it will fix the card issue.
 
Basic setup mentions:
 
By default, Home Assistant will try to detect your location from IP address geolocation. Home Assistant will automatically select a temperature unit and time zone based on this location.
 
I do have defined 1-wire temperature sensors (in updated MagicHome Espurna modules) in the section below weather that look like this:
 
 

sensor 6:  - platform: mqtt    name: "Kitchen_1Wire"    state_topic: "Kitchen-LED2/temperature"    unit_of_measurement: '  F'

 

Found this:

Separate climate platform and presentation units
 
 

 

[arakasi55]

Thanks, ill Try removing it and see how it goes.

Regarding your linked article, it seems to be the opposite of my particular issue:
This overload of meanings means that values are converted to the user's desired display unit, but the string which is appended for display is the unit used by the platform (often times not configurable).

My issue is that the measurement string is correct, but the displayed values are wrong

Thanks again for your help, really appreciate it.

 

[Comso]

Seems most (all) here are using OmniLinkBridge to link their Omni to their HA configs, but is anyone still using this for SmartThings integration?  I've been playing with both, and have been leaning towards ST of late. 
 
The one piece I seem to get hung up on is that I can't get the Hub Mode to update correctly on ST.  Regardless of the state change, the module keeps instructing ST to change the mode to "Home", which it already is in.  This doesn't matter if I arm, disarm, vacation, night, etc, on the Omni.
 
Anyone run into this problem?
 
If there's another forum focused or thread more focused on ST with OmniLinkBridge, feel free to send me there.

 

[pete_c]

Welcome to the Cocoontech forum Comso.
 
Here a few months ago deleted my Smartthings configuration and reinstalled it per GiHub documentation located over here ==>
 
hxxps://github.com/excaliburpartners/SmartThings-OmniPro
 
Everything appeared to be working OK at the time of the redo.
 
Just recently (last couple of weeks) shut off the Smartthings hub and currently enabled the Hubitat Elevation Hub.
 
This is the right place for discussion related to the ST except there has been little discussion on the forum relating to the SmartThings-OmniPro software.

 

[Comso]

This is the right place for discussion related to the ST except there has been little discussion on the forum relating to the SmartThings-OmniPro software.

 
Thanks for the great answer, and steering me to check out Hubitat as well!

 

[arakasi55]

Never have used
 
temperature_unit:C
 
under the location in the configuration yaml file.   Remove it.  I don't know if it will fix the card issue.
 
 

Hi Pete, I removed this line but it has had no effect. I am all but convinced it has to do with the thermostat code in OmniLinkBridge but cannot find a way to contact Ryan short of logging an issue on his GitHub

 

[pete_c]

.....and steering me to check out Hubitat as well!
 
I do not know anything about Hubitat and all I did was the initial configuration. 
 
Relating to SmartThings hubs have not used it that much lately so took it off line (removed two of them).
 
Relating to automation / security here utilizing Homeseer and Home Assistant.  Works great.  Also testing the HA Alexa media player options (commands and TTS).

 

[pete_c]

contact Ryan short of logging an issue on his GitHub
 
Personally would log an issue on Ryan's GitHub.

 

[grantlewis]

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. 

 
Thank you, @123. It's taken me a while to get back to this -- my apologies. I'm picking up the thread once again. (FYI I'm now running HA 0.94.0 / Hassbian on a RPi3 and so now have more "hands on" access to Home Assistant.)
 
You're correct on all counts (of course). I've confirmed that disabling Discovery removes the thermostats. MQTT Explorer shows the two entities:
 

thermostat1

current_operation = idle
current_temperature = 75
current_humidity = 0
temperature_heat_state = 64
temperature_cool_state = 75
humidify_state = 45
dehumidify_state = 60
mode_state = auto
fan_mode_state = auto
hold_state = off

thermostat2

current_operation = idle
current_temperature = 75
current_humidity = 53
temperature_heat_state = 64
temperature_cool_state = 75
humidify_state = 45
dehumidify_state = 60
mode_state = auto
fan_mode_state = auto
hold_state = off
 
Thanks to being a rube, I'm not sure if there are discovery topics / retained messages.
 
I believe I'm reading in your earlier post that specifying a unique_id in configuration.yaml for each thermostat will cause them to be registered in core.entity_registry. Will doing so remove the error message I'm seeing? A nudge on how to do so would be very much appreciated. If not, is there some other rune to cast?
 
Getting rid of the error is really my only objective. I'm happy to see the thermostats in HA, but I'd consider it to be a bonus, not a necessity.
 
THANK YOU.

 

[pete_c]

Did you fix your issue Grant?
 
Here starting to see this thermostat issue crop up....using version 0.93.1...
 
[sharedmedia=gallery:images:1183]