OmniLinkBridge to integrate Home Assistant, SmartThings, Node-RED

[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.

 

[grantlewis]

I'm continuing to try and diagnose a problem I've had with HA since 0.84.6. Right now that effort involves a fresh install of HA, disabling Omni Pro Bridge, and removing all custom_components.
 
Having done those things, I'm still seeing these messages in my log:
 
2019-04-17 16:49:30 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-04-17 16:49:30 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]. 
 
Aren't the temperature_low and temperature_high topics from the Omni? Since I've disabled OPB, I can't figure out why those messages are appearing.
 
Ideas?
 
HA version 0.91.4 (was using OmniLinkBridge version 1.1.3) on Windows 10. 

 

[pete_c]

Devices are sticky if you keep the HA DBs.  I delete the DBs here to start again. 

 

[grantlewis]

Devices are sticky if you keep the HA DBs.  I delete the DBs here to start again. 

 
Are you referring to home-assistant_v2.db? Because I've tried shutting down HA, deleting that file, and then rebooting. OmniPro Bridge is not running, but those temperature warnings are still appearing.
 

2019-04-18 14:48:59 WARNING (MainThread) [homeassistant.components.http] Configuring api_password via the http component has been deprecated. Use the legacy api password auth provider instead. For instructions, see https://www.home-assistant.io/docs/authentication/providers/#legacy-api-password
2019-04-18 14:49:00 WARNING (MainThread) [homeassistant.components.http.auth] legacy_api_password support has been enabled.
2019-04-18 14:49:04 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-04-18 14:49:04 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-04-18 14:44:37 WARNING (MainThread) [homeassistant.setup] Setup of lutron is taking over 10 seconds.

 
Also odd: I'm not seeing anything in the log about the database being upgraded after it's been deleted.

 

[pete_c]

I delete all of the DBs...doesn't matter though cuz you still have the Python scripts running and the high low stuff is not fixed yet.
 
Delete all of the files under the custom components...
 
/opt/home-assistant/config/custom_components/mqtt# ls

1 - alarm_control_panel.py 
2 - climate.py 
3 - __pycache__

Been writing some automation scripts and event type stuff so always save these when I start all over again and I have done that a few times now as I am integrating my Alexa devices to HA (and Squeezeplayers).

 

[grantlewis]

Thanks for the reply, Pete.
 
A bit more context might be helpful. Although I have a stable, 99% working Home Assistant system that uses OmniPro Bridge, at 0.84.6, its quite old. Some of the Hass.io add-ins for that version are no longer supported, and it's missing features. I need a path forward.
 
When I try to upgrade past that version, however, I start having problems. I'm in the process of troubleshooting where the problem may be. 
 
One of my first troubleshooting steps was to migrate from Hass.io on a Raspberry Pi3 to Virtual Box (Ubuntu 64). That gives me the freedom to troubleshoot for a while and then easily return to my working 0.84.6. My latest attempt is with HA 0.91.4.
 
So my question from earlier today concerns 0.91.4. In an effort to get as "vanilla" a system as possible, I installed it fresh, not as an upgrade. It has no custom_components at all. It should be completely agnostic of OmniPro Bridge.
 
So you see my confusion. I have no idea how those temp warnings are being generated as currently there are no references to OmniPro Bridge in that 0.91.4 system.
 
Since it's virtual, I could, I suppose just back up all of its .yaml files, wipe the setup, and start fresh. Maybe that's the next best step.

 

[123]

 I have no idea how those temp warnings are being generated as currently there are no references to OmniPro Bridge in that 0.91.4 system.

 
Does the configuration file contain an entry for a climate component?
 
The error messages you've received concern options (keys) that are not supported by the stock version of the MQTT climate component. The listed options were supported by the custom climate component developed by rsw686. However, you've stated you're not using any custom components in this new system. Therefore climate options like 'temperature_low_state_topic' are invalid and reported by Home Assistant in its log.
 
https://www.home-assistant.io/components/climate.mqtt/

 

[grantlewis]

Does the configuration file contain an entry for a climate component?

 
No, nothing concerning climate in any of the following:
 
automations.yaml
configuration.yaml
customize.yaml
groups.yaml
known_devices.yaml
scripts.yaml
secrets.yaml
sensors.yaml
zones.yaml
 
For grins I also checked these in the .storage folder:
 
core.config_entries
core.device_registry
core.entity_registry
core.restore_state
 
The only place I can find anything related to climate are these entities in the States panel:
 

 
No guess as to how those entities are showing up there.

 

[pete_c]

Sort of have done the same here with a from scratch build on my Armbian Ubuntu 18.04 64 bit box...using 0.92.0b1 which was the latest for aarch64 as of yesterday.

Just started HA with no edits to the configuration.yaml
 
and see log entries.

Unable to find services.yaml for the logbook integration
6:18 PM helpers/service.py (WARNING)
Unable to find services.yaml for the stream integration
6:18 PM helpers/service.py (WARNING)
Unable to find services.yaml for the script integration
6:18 PM helpers/service.py (WARNING)
Unable to load /config/known_devices.yaml: Config file not found: /config/known_devices.yaml
6:17 PM components/device_tracker/__init__.py (ERROR)

Docker OmniLinkBridge is not running nor installed yet.
 
Squeezeplayers show up with no edits here.
 


Installed docker OmniLinkBridge and started it...note nothing is configured in HA.

root@ICS-Pine64:/opt/omnilink-bridge# docker container logs omnilink-bridge
OmniLinkBridge.CoreServer: 2019-04-18 18:35:33,750 DEBUG: Starting up server 1.1.3.0
OmniLinkBridge.Modules.OmniLinkII: 2019-04-18 18:35:35,065 INFO : CONNECTION STATUS: Connecting
OmniLinkBridge.Modules.OmniLinkII: 2019-04-18 18:35:35,223 INFO : CONTROLLER IS: OmniPro II (4.0B)
OmniLinkBridge.Modules.OmniLinkII: 2019-04-18 18:35:35,235 DEBUG: Retrieving named units
OmniLinkBridge.Modules.OmniLinkII: 2019-04-18 18:35:35,370 DEBUG: Waiting for named units Area
OmniLinkBridge.Modules.OmniLinkII: 2019-04-18 18:35:35,432 DEBUG: Waiting for named units Zone
OmniLinkBridge.WebServiceModule: 2019-04-18 18:35:35,772 INFO : Listening on %5Burl="http://0.0.0.0:8000/"]http://0.0.0.0:8000/[/URL]
OmniLinkBridge.Modules.OmniLinkII: 2019-04-18 18:35:36,304 DEBUG: Waiting for named units Thermostat
OmniLinkBridge.Modules.OmniLinkII: 2019-04-18 18:35:36,410 DEBUG: Added thermostat to watch list Thermostat 1
OmniLinkBridge.Modules.OmniLinkII: 2019-04-18 18:35:36,482 DEBUG: Polling status received for Thermostat Thermostat 1
OmniLinkBridge.Modules.OmniLinkII: 2019-04-18 18:35:36,544 DEBUG: Waiting for named units Unit
OmniLinkBridge.Modules.OmniLinkII: 2019-04-18 18:35:38,721 DEBUG: Waiting for named units Message
OmniLinkBridge.Modules.OmniLinkII: 2019-04-18 18:35:38,898 DEBUG: Waiting for named units Button
OmniLinkBridge.Modules.OmniLinkII: 2019-04-18 18:35:39,018 INFO : Unsolicited notifications enabled
OmniLinkBridge.Modules.MQTTModule: 2019-04-18 18:35:39,048 DEBUG: Publishing areas

Restarted HA.
 
Same log entries as above.  No errors relating to temps et al.
 
Current base configuration directory shows:
 
 

root@ICS-Pine64:/opt/home-assistant/config# ls -l
total 284
-rw-r--r-- 1 root root      2 Apr 18 08:17 automations.yaml
-rw-r--r-- 1 root root    992 Apr 18 08:17 configuration.yaml
-rw-r--r-- 1 root root      0 Apr 18 08:17 customize.yaml
drwxr-xr-x 2 root root   4096 Apr 18 08:17 deps
-rw-r--r-- 1 root root      0 Apr 18 08:17 groups.yaml
-rw-r--r-- 1 root root    562 Apr 18 18:39 home-assistant.log
-rw-r--r-- 1 root root 266240 Apr 18 18:42 home-assistant_v2.db
-rw-r--r-- 1 root root      0 Apr 18 08:17 scripts.yaml
-rw-r--r-- 1 root root    157 Apr 18 08:17 secrets.yaml
drwxr-xr-x 2 root root   4096 Apr 18 08:18 tts

 
Personally delete or remove HA again and install it again.

 

[123]

 
No, nothing concerning climate in any of the following:
...
 
For grins I also checked these in the .storage folder:
 
..
 
The only place I can find anything related to climate are these entities in the States panel:
 
No guess as to how those entities are showing up there.

 
Well those two climate entities shown in the States panel aren't materializing out of thin air. Even if the two thermostats were found via MQTT Discovery (so not explicitly defined in configuration.yaml) , they would become registered in core.entity_registry. There really aren't any other places for an entity to be defined.
 
Open a terminal window on the Home Assistant host server, change to the config directory and run this command:

grep -rni "climate.lower_tstat"
 
It will search all files in the config directory for "climate.lower_tstat" as well as recursively search all files in all sub-directories.
 
Here's the results I get when I search for my lone thermostat called "climate.thermostat".
 
 

automations.yaml:297:#       entity_id: climate.thermostat
ui-lovelace_test.yaml:43:      #   entity: climate.thermostat
Binary file home-assistant_v2.db matches
customize.yaml:89:climate.thermostat:
sensors.yaml:111:    entity_id: climate.thermostat
sensors.yaml:286:      #   value_template: "{{ state_attr('climate.thermostat', 'temperature') }}"
grep: .storage/auth: Permission denied
.storage/core.entity_registry:215:                "entity_id": "climate.thermostat",
configuration.yaml:237:      - climate.thermostat
groups.yaml:9:      - climate.thermostat
ui-lovelace.yaml:105:      #   entity: climate.thermostat
ui-lovelace.yaml:121:          - climate.thermostat
ui-lovelace.yaml:126:      #   entity: climate.thermostat
 
 
The key thing gleaned from the results is that climate.thermostat is defined in configuration.yaml as well as core.entity_registry. That's because I manually defined it in configuration.yaml and assigned it a unique_id. Once a manually defined entity is assigned a unique_id, Home Assistant will automatically register it in core.entity_registry (so that's why the entity appears in both files). 

 

[123]

....using 0.92.0b1

 
You've encountered a known issue in 092.0 beta 1.
See: Add missing services.yaml files

 

[grantlewis]

Open a terminal window on the Home Assistant host server, change to the config directory and run this command:

 
Not sure how to do this with Hass.io.

core-ssh:~# ls
core-ssh:~# cd config
-bash: cd: config: No such file or directory
core-ssh:~# 

 

[pete_c]

Thank you 123.
 
This is one test build running on the Pine64 which I just upgraded today.
 
Other computer is running V89.1 and is doing OK right now.

 

[pete_c]

@grant,
 
On your new build did you edit the configuration.yaml file to include the MQTT stuff pointing to the Mosquitto IP?
 
Is it still running anywhere else.
 
In the above new build I mentioned I have not configured or edited any part of the configuration.yaml file.
 
I think the configuration files for hassio are installed under a dot directory in the home user directory.
 
It might be better first to delete your new installation and start from scratch.  It really does not take long to delete it and reinstall it.

 

[grantlewis]

@Pete, no. The only references to MQTT in my configuration.yaml are to enable MQTT in general and then to provide access to several Sonoff switches:
 

 

mqtt:
  broker: localhost
  username: !secret mqtt_username
  password: !secret mqtt_password
  discovery: true
  discovery_prefix: homeassistant


switch:
  - platform: mqtt
    name: "Back Porch Lamp"
    command_topic: "cmnd/sonoff_basic_01/power"
    state_topic: "stat/sonoff_basic_01/POWER"
    qos: 1
    payload_on: "ON"
    payload_off: "OFF"
    retain: true

 (etc.)