OmniLinkBridge to integrate Home Assistant, SmartThings, Node-RED

That configuration appears to be the one I posted here but with its topics modified for Omnilink.
 
That configuration is designed to work with my customized version of MQTT HVAC (i.e. the MQTT climate component). It's not the same as rsw686's customized version of the same climate component.
 
 
Unlike rsw686's version of the MQTT climate component, mine does not support separate 'target temperature settings for low and high'. Therefore it's not likely to work well for you. Conversely, the configuration you posted won't work with rsw686's version because it uses different options (like "activity_state_topic").
 
 
It's my understanding that rsw686 is submitting his modified version to become part of the standard MQTT climate component. The Pull Request is here. Once it is part of the standard release, there'll be no need for special instructions to install it as a custom component (like mine).
 
 
On the other hand, if you're just curious to see my version in operation (with the understanding that it lacks settings for low/high temperature targets), this post contains a link to the code and installation instructions.
 
 
For best results with omnilink, you'll need to wait for rsw686's version to be released with 0.89 compatibility.
 
Thank-you 123.
 
Understood regarding your climate component and it being different than Ryan's climate / thermostat stuff.
 
I like your Lovelace UI cards.  That said still getting used to using the Lovelace UI.
 
Using SonOff basics here upgraded to Espurna firmware for 1-Wire temperature hubs noticed that most recent firmware makes MQTT not work such that I downgraded Espurna 1.13.5 to 1.13.3 yesterday.
 
123 said:
It's my understanding that rsw686 is submitting his modified version to become part of the standard MQTT climate component. The Pull Request is here. Once it is part of the standard release, there'll be no need for special instructions to install it as a custom component (like mine).
Click to expand...
 
Yes the goal is to have the low and high temp setpoints included into the standard release. I just updated the pull request and it is passing all tests. Hopefully it can be merged shortly and included n the next release.
 
123 said:
On the other hand, if you're just curious to see my version in operation (with the understanding that it lacks settings for low/high temperature targets), this post contains a link to the code and installation instructions.
Click to expand...
 
Was your version the one that showed when the system was idle vs active? If so we should merge your changes with mine and get it included into the base install. The stock component shades in green when the unit is configured to auto, heat, or cool and not when it is actually running, which is pointless.
 
rsw686 said:
… which is pointless.
Click to expand...
 
You have no idea how it good it is to hear someone say that. Indeed it is pointless and I'm surprised its been allowed to work that way for so long. It was one of the first things I bumped into when I first started with Home Assistant last fall.
 
The climate component can understand the difference the operating mode and the current operating state, it's just that the MQTT climate platform doesn't make the distinction and so the state is always equal to the mode (and the resulting graph shows the furnace is always heating). Pointless.
 
There's an existing Pull Request to add 'state awareness' to the MQTT climate platform.
https://github.com/home-assistant/home-assistant/pull/20866
 
This is not the author's first try to fix it. Here's the previous attempt in October 2018:
https://github.com/home-assistant/home-assistant/pull/17414
 
If you read through that one, you'll see there's some controversy. Paulus didn't like the way the component directly acted on the state. This is surprising because I'm quite certain I've seen other components do exactly that. I feel the recommended way of doing it indicates the reviewers did not understand the proposed modification. Alternately, they no longer like the way it has been done and now want to do it differently. Whatever, The whole point is to set the component's state based on information received and not by inferring it from other parameters.

Anyhow, my custom component acts on the state directly and gets the job done very neatly. Here's the latest version designed for use with 0.89 and contains comments explaining what I've added/modified. https://pastebin.com/v4GShrYD
 
 
In a nutshell:
  • Added STATE_IDLE.
  • Added three command templates so  the end-user can optionally convert the outbound payloads.
  • mode_command_template
  • fan_mode_command_template
  • hold_command_template
  • Added 'activity_state_topic' and 'activity_state_template' to optionally receive the HVAC system's current activity (it's current state). The constraint here is that the template must convert the HVAC's current activity into one of the valid states understood by Home Assistant (idle, heat, cool).
  • Also added a new method: handle_activity_state_received
  • Added a new method to handle the state. This is the one that uses activity_state_topic to set the state to either idle, heat, or cool. It's also the supposedly controversial design choice.
Code: 
    # Modification
    # Added new method: state
    @property
    def state(self):
        # Return the current state.
        if self._topic[CONF_ACTIVITY_STATE_TOPIC] is not None:
            return self._state
        return super().state
  • Miscellaneous modifications to existing methods to support the new templates.
 
I've been trying to resolve a problem that cropped up in January after trying to upgrade from HA 0.84.6. That's been an uphill climb. Today I turned my attention to OmniLinkBridge to see if I could spot a problem there. Pulling up the logs, I see this in log.txt20190330:
 



2019-03-30 15:38:32,412 [41] WARN  OmniLinkBridge.Modules.OmniLinkII - CONNECTION STATUS: Retrying
2019-03-30 15:38:37,413 [41] WARN  OmniLinkBridge.Modules.OmniLinkII - CONNECTION STATUS: Retrying
2019-03-30 18:33:38,790 [37] WARN  OmniLinkBridge.Modules.OmniLinkII - CONNECTION STATUS: Retrying
2019-03-30 18:33:43,803 [94] WARN  OmniLinkBridge.Modules.OmniLinkII - CONNECTION STATUS: Retrying
2019-03-30 18:33:50,804 [87] WARN  OmniLinkBridge.Modules.OmniLinkII - CONNECTION STATUS: Retrying
2019-03-30 18:33:54,946 [76] ERROR OmniLinkBridge.Modules.OmniLinkII - CONNECTION STATUS: Connection Timed Out 
2019-03-30 18:33:59,806 [87] WARN  OmniLinkBridge.Modules.OmniLinkII - CONNECTION STATUS: Retrying
2019-03-30 18:34:22,216 [66] ERROR OmniLinkBridge.Modules.OmniLinkII - CONNECTION STATUS: Connection Timed Out
2019-03-30 18:34:30,016 [87] WARN  OmniLinkBridge.Modules.OmniLinkII - Not logging out of date status for Thermostat Lower Tstat
2019-03-30 18:34:30,016 [87] WARN  OmniLinkBridge.Modules.OmniLinkII - Not logging out of date status for Thermostat Upper Tstat
2019-03-30 18:36:00,116 [10] WARN  OmniLinkBridge.Modules.TimeSyncModule - Controller time 03/30/2019 18:35:24 out of sync by 36.116442 seconds
2019-03-30 18:36:40,135 [15] WARN  OmniLinkBridge.Modules.OmniLinkII - CONNECTION STATUS: Retrying
2019-03-30 18:38:48,364 [16] WARN  OmniLinkBridge.Modules.OmniLinkII - CONNECTION STATUS: Retrying
2019-03-30 18:40:02,788 [16] WARN  OmniLinkBridge.Modules.OmniLinkII - CONNECTION STATUS: Retrying
2019-03-30 18:40:17,133 [16] WARN  OmniLinkBridge.Modules.OmniLinkII - CONNECTION STATUS: Retrying
2019-03-30 18:40:20,852 [20] WARN  OmniLinkBridge.Modules.OmniLinkII - CONNECTION STATUS: Retrying
2019-03-30 18:40:34,776 [20] WARN  OmniLinkBridge.Modules.OmniLinkII - CONNECTION STATUS: Retrying
2019-03-30 18:41:08,883 [16] WARN  OmniLinkBridge.Modules.OmniLinkII - CONNECTION STATUS: Retrying
2019-03-30 18:41:13,899 [20] WARN  OmniLinkBridge.Modules.OmniLinkII - CONNECTION STATUS: Retrying
2019-03-30 18:41:23,165 [20] WARN  OmniLinkBridge.Modules.OmniLinkII - CONNECTION STATUS: Retrying
2019-03-30 18:42:13,616 [28] WARN  OmniLinkBridge.Modules.OmniLinkII - CONNECTION STATUS: Retrying
2019-03-30 18:45:03,963 [20] WARN  OmniLinkBridge.Modules.OmniLinkII - CONNECTION STATUS: Retrying
2019-03-30 18:45:43,567 [20] WARN  OmniLinkBridge.Modules.OmniLinkII - CONNECTION STATUS: Retrying
2019-03-30 18:48:26,826 [20] WARN  OmniLinkBridge.Modules.OmniLinkII - CONNECTION STATUS: Retrying
2019-03-30 18:48:31,841 [20] WARN  OmniLinkBridge.Modules.OmniLinkII - CONNECTION STATUS: Retrying
2019-03-30 19:15:23,793 [19] WARN  OmniLinkBridge.Modules.OmniLinkII - CONNECTION STATUS: Retrying
2019-03-30 19:42:03,916 [75] WARN  OmniLinkBridge.Modules.OmniLinkII - CONNECTION STATUS: Retrying
2019-03-30 21:15:24,182 [91] WARN  OmniLinkBridge.Modules.OmniLinkII - CONNECTION STATUS: Retrying
2019-03-30 21:15:29,182 [91] WARN  OmniLinkBridge.Modules.OmniLinkII - CONNECTION STATUS: Retrying
2019-03-30 21:15:43,058 [91] WARN  OmniLinkBridge.Modules.OmniLinkII - CONNECTION STATUS: Retrying
2019-03-30 21:15:48,543 [91] WARN  OmniLinkBridge.Modules.OmniLinkII - CONNECTION STATUS: Retrying
2019-03-30 21:15:55,549 [94] WARN  OmniLinkBridge.Modules.OmniLinkII - CONNECTION STATUS: Retrying
2019-03-30 21:16:04,551 [94] WARN  OmniLinkBridge.Modules.OmniLinkII - CONNECTION STATUS: Retrying
2019-03-30 21:17:17,540 [91] WARN  OmniLinkBridge.Modules.OmniLinkII - CONNECTION STATUS: Retrying
2019-03-30 21:17:23,025 [91] WARN  OmniLinkBridge.Modules.OmniLinkII - CONNECTION STATUS: Retrying
2019-03-30 21:17:54,755 [91] WARN  OmniLinkBridge.Modules.OmniLinkII - CONNECTION STATUS: Retrying
2019-03-30 22:52:50,902 [47] WARN  OmniLinkBridge.Modules.OmniLinkII - CONNECTION STATUS: Retrying
2019-03-30 22:52:55,918 [47] WARN  OmniLinkBridge.Modules.OmniLinkII - CONNECTION STATUS: Retrying
2019-03-30 22:54:00,015 [47] WARN  OmniLinkBridge.Modules.OmniLinkII - CONNECTION STATUS: Retrying
2019-03-30 23:00:05,488 [89] WARN  OmniLinkBridge.Modules.OmniLinkII - CONNECTION STATUS: Retrying
 


My logs go back to 2019-02-10. I see similar error warning messages in all log files since that date.
 
Anyone have a guess as to what might be going on there or what I need to do?
 
Are you running the OmniLinkBridge in Docker on Linux or regular mode on Linux or in Windows?

Here running HA version 0.90.1 and OmniLinkBridge version 1.1.3 in Docker version 18.09.04.
 
grantlewis said:
I've been trying to resolve a problem that cropped up in January after trying to upgrade from HA 0.84.6. That's been an uphill climb. Today I turned my attention to OmniLinkBridge to see if I could spot a problem there. Pulling up the logs, I see this in log.txt20190330:
 
My logs go back to 2019-02-10. I see similar error warning messages in all log files since that date.
 
Anyone have a guess as to what might be going on there or what I need to do?
Click to expand...
 
The OmniLinkBridge is loosing connection the the HAI / Leviton controller. Might be a network connectivity issue?
 
pete_c said:
Are you running the OmniLinkBridge in Docker on Linux or regular mode on Linux or in Windows?

Here running HA version 0.90.1 and OmniLinkBridge version 1.1.3 in Docker version 18.09.04.
Click to expand...
 
Regular mode on Windows.
 
rsw686 said:
The OmniLinkBridge is loosing connection the the HAI / Leviton controller. Might be a network connectivity issue?
Click to expand...
 
Sounds reasonable. Any monitoring/logging tools for Windows 10 that you could recommend?
 
Have a look at the Windows event logs.  How many devices do you have on the LAN that the OmniPro is connected to?
 
pete_c said:
Have a look at the Windows event logs.  How many devices do you have on the LAN that the OmniPro is connected to?
Click to expand...
 
Happy to provide that info... if only I could find it. It's kind of a forest/trees quandary. Could you kindly tell me where to look?
 

  • Right-click or tap and hold the Start icon. Choose Event Viewer.
    The Event Viewer appears.

  • On the left, choose Event Viewer, Custom Views, Administrative Events.
event viewer.jpg

Also check to make sure that Windows 10 AV is letting the application run.
 
It's been reported that Windows 10 updates ...specifically 18.09 does some wierd stuff to the OS.  IE: deletes software and hardware connectivity.
 
Here mostly utilize Linux these days.  I did recently configure a Windows 2016 server for Windows stuff via RDP.  It is a much nicer compact  build of Windows.  No eye candy and seems to function a bit better than Windows 10.
 
Here a few years ago put a micro router between the OmniPro 2 panel and the rest of the network to fix the OP2 network issues.  As I increased the number of devices on my home network the OmniPro 2 panel started to disconnect from the rest of the network.  First issue that I saw was the time sync was going way off, then serial device communications errors and finally network connectivity issues.
 
 
 
pete_c said:
  • Right-click or tap and hold the Start icon. Choose Event Viewer.
    The Event Viewer appears.
  • On the left, choose Event Viewer, Custom Views, Administrative Events.
attachicon.gif
event viewer.jpg
Click to expand...
 
Thanks -- I appreciate the clear instructions. I'm linking to a .csv of all events from 3/22 - 3/31. I glanced through but nothing in particular caught my eye. Would you mind checking?
 
https://www.dropbox.com/s/omu4ir39ni1kmte/events_03_22_thru_03_31.csv?dl=1
 
You must log in or register to reply here.

Similar threads

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