OmniLinkBridge to integrate Home Assistant, SmartThings, Node-RED
- Thread starter rsw686
- Start date
jmorris644
Active Member
I have it running just great on a RPI. I used Mono and did not use Docker.sawadee2 said:
Joe
pete_c
Guru
Followed the instructions here to install it:
hxxps://github.com/excaliburpartners/OmniLinkBridge
[*]Run as interactive to verify connectivity
[*]Add systemd file and configure paths
[*]Enable at boot and start service
Here tested it on an RPi2 POE connected and running in the attic using it as a ZWave controller, Node Red, HA server, OmniLinkBridge server, NOAA satellite map downloader, OWFS server and testing HA Genie (and other linux automation software).
Also tested it on a Pine64 2Gb computer running HS3 and Ubuntu 18.04 64 bit and another computer running Windows server 2016.
hxxps://github.com/excaliburpartners/OmniLinkBridge
- Copy files to your desired location like /opt/OmniLinkBridge
- Configure at a minimum the controller IP and encryptions keys
vim OmniLinkBridge.ini or nano OmniLinkBridge.ini
[*]Run as interactive to verify connectivity
- mono OmniLinkBridge.exe -i
[*]Add systemd file and configure paths
- cp omnilinkbridge.service /etc/systemd/system/
- vim /etc/systemd/system/omnilinkbridge.service
- systemctl daemon-reload
[*]Enable at boot and start service
- systemctl enable omnilinkbridge.service
- systemctl start omnilinkbridge.service
Here tested it on an RPi2 POE connected and running in the attic using it as a ZWave controller, Node Red, HA server, OmniLinkBridge server, NOAA satellite map downloader, OWFS server and testing HA Genie (and other linux automation software).
Also tested it on a Pine64 2Gb computer running HS3 and Ubuntu 18.04 64 bit and another computer running Windows server 2016.
Code:
2019-02-24 21:22:24 WARNING (MainThread) [homeassistant.helpers.config_validation] Your configuration contains extra keys that the platform does not support.,Please remove [temperature_low_state_topic], [temperature_low_command_topic], [temperature_high_state_topic], [temperature_high_command_topic]. ,Also installed Mosquitto, and mono.
For now can see OmnLinkBridge.Modules.OmniLinkII polling status messages showing up. All this on a RPI 3B. I do have a couple of Pine64 2GB boards and may off load a bit in the future.
Just trying to learn at this point. Now have to work with HA configuration to make use of this added resource.
I am seeing this and not sure if it is something I caused or some returned status no coded yet..
Thank you for a great addition to HA which will give new life to my OmniPro II.
mtgoat
Member
Attempting to install OmniLinkBridge on a Mac Mini (that doesn't support Docker.)
I have it running successfully via Mono (step 3), but need help with Mac OS equivalents for systemctl steps 4 & 5:
[Edit: Or...do I need a plist file instead/also?]
Installation Linux
I have it running successfully via Mono (step 3), but need help with Mac OS equivalents for systemctl steps 4 & 5:
[Edit: Or...do I need a plist file instead/also?]
Installation Linux
- Copy files to your desired location like /opt/OmniLinkBridge
- Configure at a minimum the controller IP and encryptions keys
- vim OmniLinkBridge.ini
- Run as interactive to verify connectivity
- mono OmniLinkBridge.exe -i
- Add systemd file and configure paths
- cp omnilinkbridge.service /etc/systemd/system/
- vim /etc/systemd/system/omnilinkbridge.service
- systemctl daemon-reload
- Enable at boot and start service
- systemctl enable omnilinkbridge.service
- systemctl start omnilinkbridge.service
pete_c
Guru
The Linux service start is a script that is documented to start mono application.
Googling how to use services on a Mac found this link:
hxxps://www.macworld.com/article/1163996/software-utilities/how-to-use-services-in-mac-os-x.html
BTW you can also install Docker on a MAC. See here:
hxxps://docs.docker.com/docker-for-mac/install/
Googling how to use services on a Mac found this link:
hxxps://www.macworld.com/article/1163996/software-utilities/how-to-use-services-in-mac-os-x.html
BTW you can also install Docker on a MAC. See here:
hxxps://docs.docker.com/docker-for-mac/install/
grantlewis
Active Member
Seeing this error in 0.88.2, running OmniLinkBridge_1.1.3:
Log Details (WARNING)
Thu Mar 07 2019 17:25:29 GMT-0500 (Eastern Standard Time)
Your configuration contains extra keys that the platform does not support.
Please remove [temperature_low_state_topic], [temperature_low_command_topic], [temperature_high_state_topic], [temperature_high_command_topic].
Service climate/set_operation_mode called.
In addition a config warning displays in the UI:
Your configuration contains extra keys that the platform does not support (but were silently accepted before 0.88). Please find and remove the following. This will become a breaking change.
* [temperature_low_state_topic],
[temperature_low_command_topic],
[temperature_high_state_topic],
[temperature_high_command_topic].
A screen cap of one thermostat's control in the UI :
Log Details (WARNING)
Thu Mar 07 2019 17:25:29 GMT-0500 (Eastern Standard Time)
Your configuration contains extra keys that the platform does not support.
Please remove [temperature_low_state_topic], [temperature_low_command_topic], [temperature_high_state_topic], [temperature_high_command_topic].
Service climate/set_operation_mode called.
In addition a config warning displays in the UI:
Your configuration contains extra keys that the platform does not support (but were silently accepted before 0.88). Please find and remove the following. This will become a breaking change.
* [temperature_low_state_topic],
[temperature_low_command_topic],
[temperature_high_state_topic],
[temperature_high_command_topic].
A screen cap of one thermostat's control in the UI :
pete_c
Guru
Updated here from HA 87.1 to HA 89.1 today and see the same as above when starting Home Assistant using OmniLinkBridge
2019-03-11 10:14:07 WARNING (MainThread) [homeassistant.helpers.config_validation] Your configuration contains extra keys that the platform does not support.
Please remove [temperature_low_state_topic], [temperature_low_command_topic], [temperature_high_state_topic][temperature_high_command_topic].
2019-03-11 10:14:07 WARNING (MainThread) [homeassistant.helpers.config_validation] Your configuration contains extra keys that the platform does not support.
Please remove [temperature_low_state_topic], [temperature_low_command_topic], [temperature_high_state_topic][temperature_high_command_topic].
123
Senior Member
The error message "Your configuration contains extra keys that the platform does not support." is because 0.89 is not using your custom component for MQTT HVAC.
The custom version knows how to handle the 'extra keys' (a.k.a. options) whereas the stock version does not.
Home Assistant 0.89 isn't using your custom component due to changes brought on by the "Great Migration". This is a project to re-organize the way the source code is structured. One of the consequences is that the location of custom components has changed (and then some).
I'll borrow one of my own explanations from this post:
Prior to 0.88, you would copy the customized version of MQTT HVAC to:
custom_components/climate/mqtt.py
For 0.88, you copy the customized version of MQTT HVAC to:
custom_components/mqtt/climate.py
For 0.89, you copy the customized version of MQTT HVAC to:
custom_components/mqtt/climate.py
If you feel the new way of doing things obliges you to copy way more than you expected, that's by design. Under the system, you can no longer have 'partial overlays'. In other words, you can no longer make Home Assistant use your customized version of MQTT HVAC from one directory while using all other MQTT-related components from the standard directory. It's one or the other. As soon as it finds one usable MQTT component in `custom_components` it will no longer look for other MQTT components in `components`. There will be a benefit to it but that comes in a future version. For now, it's just feels more complicated and messy than in the past.
There are ways around it. In other words, you can emulate 'partial overlays' using approaches I've called 'derivation' or 'redirection'. Both have pros and cons (I'm using derivation because it makes installation about as easy as it was in the past). I summarized the three approaches in this post. I recommend you review it and decide which is best for you.
BTW, regardless of which approach is chosen (full replacement, derivation, redirection), the customized version of MQTT HVAC you are currently using will require additional tweaking to make it work with 0.89. So if you think it's only a matter of putting what you have now into the correct directory, it's not.
The custom version knows how to handle the 'extra keys' (a.k.a. options) whereas the stock version does not.
Home Assistant 0.89 isn't using your custom component due to changes brought on by the "Great Migration". This is a project to re-organize the way the source code is structured. One of the consequences is that the location of custom components has changed (and then some).
I'll borrow one of my own explanations from this post:
Prior to 0.88, you would copy the customized version of MQTT HVAC to:
custom_components/climate/mqtt.py
For 0.88, you copy the customized version of MQTT HVAC to:
custom_components/mqtt/climate.py
For 0.89, you copy the customized version of MQTT HVAC to:
custom_components/mqtt/climate.py
- You also have to copy components/mqtt/__init.py__ to custom_components/mqtt/__init.py__
- If you use any other MQTT components (light, switch, lock, cover, sensor, binary_sensor, etc) you will also have to copy them from components to custom_components.
- If you have automations that use mqtt.publish then you will also have to copy all of components/automation/mqtt to custom_components/automation/mqtt.
If you feel the new way of doing things obliges you to copy way more than you expected, that's by design. Under the system, you can no longer have 'partial overlays'. In other words, you can no longer make Home Assistant use your customized version of MQTT HVAC from one directory while using all other MQTT-related components from the standard directory. It's one or the other. As soon as it finds one usable MQTT component in `custom_components` it will no longer look for other MQTT components in `components`. There will be a benefit to it but that comes in a future version. For now, it's just feels more complicated and messy than in the past.
There are ways around it. In other words, you can emulate 'partial overlays' using approaches I've called 'derivation' or 'redirection'. Both have pros and cons (I'm using derivation because it makes installation about as easy as it was in the past). I summarized the three approaches in this post. I recommend you review it and decide which is best for you.
BTW, regardless of which approach is chosen (full replacement, derivation, redirection), the customized version of MQTT HVAC you are currently using will require additional tweaking to make it work with 0.89. So if you think it's only a matter of putting what you have now into the correct directory, it's not.
pete_c
Guru
Edited your Home Assistant thermostat script for use with the Omnilinkbridge.
Not sure if I got it all right. I have not yet implemented it.
climate:
- platform: mqtt
name: "thermostat1"
unique_id: '1234567890'
payload_on: 1
payload_off: 0
activity_state_topic: "omnilink/thermostat1/current_operation"
activity_state_template: >-
{% set values = { '1':'heat', '2':'cool', '4':'idle'} %}
{{ values[value] if value in values.keys() else 'idle' }}
modes:
- auto
- heat
- cool
- 'off'
mode_state_topic: "omnilink/thermostat1/mode_state"
mode_state_template: >-
{% set values = { '0':'auto', '1':'heat', '2':'cool', '4':'off'} %}
{{ values[value] if value in values.keys() else 'off' }}
mode_command_topic: "omnilink/command/thermostat1/mode_state"
mode_command_template: >-
{% set values = { 'auto':'0', 'heat':'1', 'cool':'2', 'off':'4'} %}
{{ values[value] if value in values.keys() else '4' }}
fan_modes:
- auto
- 'on'
fan_mode_state_topic: "omnilink/thermostat1/fan_mode_state"
fan_mode_state_template: >-
{% set values = { '0':'auto', '1':'on'} %}
{{ values[value] if value in values.keys() else 'auto' }}
fan_mode_command_topic: "omnilink/command/thermostat1/fan_mode_state"
fan_mode_command_template: >-
{% set values = { 'auto':'0', 'on':'1'} %}
{{ values[value] if value in values.keys() else '0' }}
current_current_temperature_topic: "omnilink/thermostat1/current_temperature"
min_temp: 17
max_temp: 28
temp_step: 0.5
current_temperature_state_topic: "omnilink/thermostat1/temperature_heat_state"
current_temperature_command_topic: "omnilink/command/thermostat1/temperature_heat_state"
hold_state_topic: "omnilink/thermostat1/hold_state"
hold_state_template: "{{ 'hold' if value == '2' else 'auto' }}"
hold_command_topic: "omnilink/command/thermostat1/hold_state"
hold_command_template: "{{ '2' if value == 'hold' else '0' }}"
Curious about the temperature_heat_state versus temperature_cool_state?
Not sure if I got it all right. I have not yet implemented it.
climate:
- platform: mqtt
name: "thermostat1"
unique_id: '1234567890'
payload_on: 1
payload_off: 0
activity_state_topic: "omnilink/thermostat1/current_operation"
activity_state_template: >-
{% set values = { '1':'heat', '2':'cool', '4':'idle'} %}
{{ values[value] if value in values.keys() else 'idle' }}
modes:
- auto
- heat
- cool
- 'off'
mode_state_topic: "omnilink/thermostat1/mode_state"
mode_state_template: >-
{% set values = { '0':'auto', '1':'heat', '2':'cool', '4':'off'} %}
{{ values[value] if value in values.keys() else 'off' }}
mode_command_topic: "omnilink/command/thermostat1/mode_state"
mode_command_template: >-
{% set values = { 'auto':'0', 'heat':'1', 'cool':'2', 'off':'4'} %}
{{ values[value] if value in values.keys() else '4' }}
fan_modes:
- auto
- 'on'
fan_mode_state_topic: "omnilink/thermostat1/fan_mode_state"
fan_mode_state_template: >-
{% set values = { '0':'auto', '1':'on'} %}
{{ values[value] if value in values.keys() else 'auto' }}
fan_mode_command_topic: "omnilink/command/thermostat1/fan_mode_state"
fan_mode_command_template: >-
{% set values = { 'auto':'0', 'on':'1'} %}
{{ values[value] if value in values.keys() else '0' }}
current_current_temperature_topic: "omnilink/thermostat1/current_temperature"
min_temp: 17
max_temp: 28
temp_step: 0.5
current_temperature_state_topic: "omnilink/thermostat1/temperature_heat_state"
current_temperature_command_topic: "omnilink/command/thermostat1/temperature_heat_state"
hold_state_topic: "omnilink/thermostat1/hold_state"
hold_state_template: "{{ 'hold' if value == '2' else 'auto' }}"
hold_command_topic: "omnilink/command/thermostat1/hold_state"
hold_command_template: "{{ '2' if value == 'hold' else '0' }}"
Curious about the temperature_heat_state versus temperature_cool_state?
