Jump to content


Photo
- - - - -

OmniLinkBridge to integrate Home Assistant, SmartThings, Node-RED


  • Please log in to reply
207 replies to this topic

#16 pete_c

pete_c

    Cocoonut

  • -=Gold Supporter=-
  • 9140 posts
  • Location:House
  • Experience:average
  • Software:Main Lobby, Open Source Automation
  • Hardware:HAI OmniPro II, Mi Casa Verde Vera, Ocelot
  • Tech:X10-PLC, X10-RF, UPB, INSTEON, Z-Wave, ZigBee, 1-Wire, xAP, xPL, ALC
  • Audio:Russound
  • Video:MythTV
  • CCTV:analog, ip, dvr
  • Phone:Asterisk, FreePBX, Ooma, POTS, VoIP via ISP

Posted 19 October 2018 - 07:51 AM

Googling the error I see with main box and running application it appears to be a bug with the interaction of current release version of Mono and MQTTnet.Extensions.ManagedClient nuget library.

 

So the fix could be just a downgrade of Mono which I do not want to do such that it'll be easier to utilize Docker as recommended by you.



#17 pete_c

pete_c

    Cocoonut

  • -=Gold Supporter=-
  • 9140 posts
  • Location:House
  • Experience:average
  • Software:Main Lobby, Open Source Automation
  • Hardware:HAI OmniPro II, Mi Casa Verde Vera, Ocelot
  • Tech:X10-PLC, X10-RF, UPB, INSTEON, Z-Wave, ZigBee, 1-Wire, xAP, xPL, ALC
  • Audio:Russound
  • Video:MythTV
  • CCTV:analog, ip, dvr
  • Phone:Asterisk, FreePBX, Ooma, POTS, VoIP via ISP

Posted 19 October 2018 - 08:02 AM

Mangled my Omnistat and aux temperature readings and get no graphs any more for history. 
 
Everything else from the panel looks good.  Might start from scratch.
 
It is configured for imperial versus metric but I don't know where to point to the additional aux climate python script. 
 
Is there a general setting for °C versus °F?
 

Attached File  climate.jpg   34.45K   8 downloads



#18 rsw686

rsw686

    Dedicated Cocooner

  • Registered
  • PipPipPip
  • 469 posts
  • Experience:guru
  • Software:Open Source Automation
  • Hardware:HAI OmniPro II
  • Tech:UPB, Z-Wave, ZigBee, 1-Wire, RadioRA2
  • Phone:Asterisk, FreePBX

Posted 19 October 2018 - 09:37 AM

Your thermostat should look like this, disregarding the graph as I've been playing with the values. I don't think the custom_component is loading on yours as you only have the single setpoint. Did you restart Home Assistant after uploading the file?

 

You can change the units in configuration.yaml by setting unit_system: imperial. Side note I have a bug in OmniLinkBridge that is fixed in the dev branch on git hub. I didn't define max_temp, which its set by default to 35 and not adjusted for F. This causes the cool setpoint to allowed to be adjusted to a higher number.

 

Attached File  hvac.PNG   18.98K   9 downloads


Edited by rsw686, 19 October 2018 - 09:38 AM.


#19 123

123

    Cocoonut

  • Registered
  • PipPipPipPip
  • 2140 posts
  • Location:Montreal, QC
  • Experience:average
  • Software:Premise
  • Hardware:Elk M1

Posted 19 October 2018 - 11:43 AM

@rsw686 I've posted a question about MQTT HVAC's history chart on the Home Assistant forum but I'm not getting any replies. I'm hoping you can answer it here, given that you are using it.


Does the history chart show a green-shaded area only when the HVAC is actively heating/cooling or whenever it is in heat/cool mode?



I'm using MQTT HVAC and it shows green whenever the furnace is in heat mode (and white when off). In other words, the furnace doesn't have to be producing heat for the chart to be green, just in heat mode. That's not useful because I'd rather see when the furnace was actively heating and not when it was in 'heat mode'.

 

 

Perhaps I've misunderstood the purpose of the topics and misconfigured it?

 

According to its documentation, mode_state_topic is for receiving the current operation mode (not its current operating state) and the values should match the optional list defined in modes (which are rendered in the UI as the Operation selector).

 

If you don't use this topic then it operates in what it calls optimistic mode and sends the selected operation mode to the thermostat without expecting an acknowledgement via the mode_state_topic. It seems clear to me that this topic is used to receive the current operating mode and there's no topic for receiving the current operating state.

 

 

Anyway, I noticed in your example that it was in Auto mode yet the history chart showed no green area. It suggests perhaps that, in your case, the green area only appears when the HVAC system is active. If so, that leaves me wondering how does it know that when there's no topic for the operating state!

Attached Files


Edited by 123, 19 October 2018 - 11:53 AM.


#20 pete_c

pete_c

    Cocoonut

  • -=Gold Supporter=-
  • 9140 posts
  • Location:House
  • Experience:average
  • Software:Main Lobby, Open Source Automation
  • Hardware:HAI OmniPro II, Mi Casa Verde Vera, Ocelot
  • Tech:X10-PLC, X10-RF, UPB, INSTEON, Z-Wave, ZigBee, 1-Wire, xAP, xPL, ALC
  • Audio:Russound
  • Video:MythTV
  • CCTV:analog, ip, dvr
  • Phone:Asterisk, FreePBX, Ooma, POTS, VoIP via ISP

Posted 20 October 2018 - 05:02 AM

Yes here trashed my Home Assistant installation to a point where it would not boot up.

I installed it twice. Once from a github and running a script for Ubuntu and the other time a line by line update and install.
 
Found it sitting at the:
 
/usr/share/hassio directory
 
and
 
/home/user/pete/homeassistant and
/home/user/pete/homeassistant
 
running in docker but it seemed to be getting its configurations from the /usr/share/hassio directory.
 
So here removing it all and starting from scratch.

#21 rsw686

rsw686

    Dedicated Cocooner

  • Registered
  • PipPipPip
  • 469 posts
  • Experience:guru
  • Software:Open Source Automation
  • Hardware:HAI OmniPro II
  • Tech:UPB, Z-Wave, ZigBee, 1-Wire, RadioRA2
  • Phone:Asterisk, FreePBX

Posted 20 October 2018 - 08:51 AM

To get started with Home Assistant on docker, assuming you have docker installed.
docker pull homeassistant/home-assistant
Then start home assistant. For the config you need to map the docker config folder to your docker host. I have my config in /opt/home-assistant/config
mkdir -p /opt/home-assistant/config
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
At this point you should be able to access Home Assistant in your browser at http://serverip:8123.

Now create a custom_components/climate folder, add the updated mqtt.py, and restart docker.
mkdir -p /opt/home-assistant/config/custom_components/climate
cd /opt/home-assistant/config/custom_components/climate
wget https://raw.githubusercontent.com/home-assistant/home-assistant/9c7e1f5c024fc2393eca0c4bb14a10233791911e/homeassistant/components/climate/mqtt.py
docker restart home-assistant
If for some reason you want to start over you can just delete the docker container and config.
docker stop home-assistant
docker rm home-assistant
rm -rf /opt/home-assistant/config/*

Edited by rsw686, 20 October 2018 - 08:52 AM.


#22 rsw686

rsw686

    Dedicated Cocooner

  • Registered
  • PipPipPip
  • 469 posts
  • Experience:guru
  • Software:Open Source Automation
  • Hardware:HAI OmniPro II
  • Tech:UPB, Z-Wave, ZigBee, 1-Wire, RadioRA2
  • Phone:Asterisk, FreePBX

Posted 20 October 2018 - 08:57 AM

@123

You are correct that mode_state_topic is the mode off, cool, heat, auto and not the operating state idle, cool, heat. From my digging in the MQTT climate module it doesn't appear that the capability to show if the system is idle, cooling, or heating is supported. I was planning to look into how to add this once my previous pull request for the low and high setpoints went through. I am publishing this to MQTT topic omnilink/thermostatX/current_operation

Edited by rsw686, 20 October 2018 - 09:00 AM.


#23 pete_c

pete_c

    Cocoonut

  • -=Gold Supporter=-
  • 9140 posts
  • Location:House
  • Experience:average
  • Software:Main Lobby, Open Source Automation
  • Hardware:HAI OmniPro II, Mi Casa Verde Vera, Ocelot
  • Tech:X10-PLC, X10-RF, UPB, INSTEON, Z-Wave, ZigBee, 1-Wire, xAP, xPL, ALC
  • Audio:Russound
  • Video:MythTV
  • CCTV:analog, ip, dvr
  • Phone:Asterisk, FreePBX, Ooma, POTS, VoIP via ISP

Posted 20 October 2018 - 08:58 AM

Thank you Ryan.

 

Yeah thinking it is better installed in OPT directory than Home directory .....the install above that I wrote puts it in the Home directory and creates systemd autostart configurations.

 

Over complicated my install above - now deleted.



#24 rsw686

rsw686

    Dedicated Cocooner

  • Registered
  • PipPipPip
  • 469 posts
  • Experience:guru
  • Software:Open Source Automation
  • Hardware:HAI OmniPro II
  • Tech:UPB, Z-Wave, ZigBee, 1-Wire, RadioRA2
  • Phone:Asterisk, FreePBX

Posted 20 October 2018 - 09:04 AM

@pete_c

Looking again at your post, you installed Hass.io, which is Home Assistant plus the add-ons, etc. I originally went this method when I had it running on a raspberry pi. However I have since moved my installed to CentOS docker host. When I did this I only installed Home Assistant per the commands I posted above.

I also installed node-red docker by hand and added the Home Assistant addon.
docker pull nodered/node-red-docker:v8
mkdir -p /opt/node-red/data
docker run -d -p 1880:1880 -v /opt/node-red/data:/data --name mynodered --user root --restart unless-stopped nodered/node-red-docker:v8
Enter a bash shell in the docker container, npm install the addon, then restart node-red.
docker exec -it mynodered /bin/bash

cd /data
npm install node-red-contrib-home-assistant
exit

docker restart mynodered

Edited by rsw686, 20 October 2018 - 09:08 AM.


#25 pete_c

pete_c

    Cocoonut

  • -=Gold Supporter=-
  • 9140 posts
  • Location:House
  • Experience:average
  • Software:Main Lobby, Open Source Automation
  • Hardware:HAI OmniPro II, Mi Casa Verde Vera, Ocelot
  • Tech:X10-PLC, X10-RF, UPB, INSTEON, Z-Wave, ZigBee, 1-Wire, xAP, xPL, ALC
  • Audio:Russound
  • Video:MythTV
  • CCTV:analog, ip, dvr
  • Phone:Asterisk, FreePBX, Ooma, POTS, VoIP via ISP

Posted 20 October 2018 - 09:42 AM

Thank you Ryan...

 

Worst that that...here installed hass.io twice the first time with multiple configuration directories.....



#26 123

123

    Cocoonut

  • Registered
  • PipPipPipPip
  • 2140 posts
  • Location:Montreal, QC
  • Experience:average
  • Software:Premise
  • Hardware:Elk M1

Posted 20 October 2018 - 11:07 AM

@123

You are correct that mode_state_topic is the mode off, cool, heat, auto and not the operating state idle, cool, heat. From my digging in the MQTT climate module it doesn't appear that the capability to show if the system is idle, cooling, or heating is supported. I was planning to look into how to add this once my previous pull request for the low and high setpoints went through. I am publishing this to MQTT topic omnilink/thermostatX/current_operation

 

I've learned that the chart history for most climate platforms shows the operating mode BUT not all of them! The Proliphix platform, charts the state.

 

"Petro" helped me understand the connection between the frontend chart-widget and the platform property driving it. I described it in detail in my latest post in this thread:

https://community.ho...y-chart/73926/7

 

In that post, I confirm that the chart is showing MQTT HVAC's operating mode, not state. For old hands on this forum, I think we can agree that it's a curious choice of parameter to chart. Seeing when the HAVC system is actively heating/cooling (its state) is more informative.

 

The author of the Proliphix platform understood that and chose to supply the chart with the HVAC system's state, not mode. Basically he used the appropriate Proliphix API call, opting for HvacState instead of HvacMode.

 

The MQTT HVAC platform needs to support a new MQTT topic representing the HVAC system's state. There's a pull request underway to create "activity_state_topic". However, it doesn't use this new topic to its full potential (set "current_operation" to state vs mode).

https://github.com/h...tant/pull/17414

 

I already have a local instance of MQTT HVAC that:

  • Automatically sets temperature step-size based on the chosen unit system (1 degree steps for imperial, 0.5 degree steps for metric).
  • Allows you to override the step-size in the config yaml.
  • Provides a MODE_COMMAND_TEMPLATE that allows you to convert the published Operation Mode (basically the other half of the existing ability to convert the subscribed Operation Mode). I needed this because mode is received as numeric values, that a template converts to  text for display in HASS, then those text values must be converted back to integers for controlling the physical thermostat. The mode_command_template is used to perform that outbound conversion.

 

I plan to embellish "activity_state_topic" so it sets the "current_operation" state as opposed to how it currently works (basing it on "mode_state_topic").

 

I don't know how to work with GitHub yet, and jump through all the qualification steps, to submit this work for official inclusion in Home Assistant's repository. So, for now, it remains a separate beast in the config/custom_components/climate directory.


Edited by 123, 20 October 2018 - 11:16 AM.


#27 rsw686

rsw686

    Dedicated Cocooner

  • Registered
  • PipPipPip
  • 469 posts
  • Experience:guru
  • Software:Open Source Automation
  • Hardware:HAI OmniPro II
  • Tech:UPB, Z-Wave, ZigBee, 1-Wire, RadioRA2
  • Phone:Asterisk, FreePBX

Posted 20 October 2018 - 02:39 PM

@123,

I agree that it should show operating state not mode. That's the one thing Home Assistant is missing as I can't tell when my HVAC system is actually running. I'd be willing to help out with this effort. I was hoping Home Assistant would accept the existing pull requests on climate/mqtt.py first so things don't get tricky to merge.

As far as development goes, create yourself an account on GitHub. Then click the fork option on the Home Assistant page. This will give you a copy of the repo in your own account.

Clone your fork of the repo to your local computer and create a branch for the feature
git clone https://github.com/YOURACCOUNT/home-assistant.git
git checkout -b climate-mqtt-feature-name
Make your changes, check the diff to make sure you have the correct changes, add the files, commit, and push the repo back to git hub.
git diff
git add .
git commit -m "Comments about your new feature"
git push origin climate-mqtt-feature-name
Go back to github and submit a pull request to Home Assistant for your branch.

#28 grantlewis

grantlewis

    Cocooner

  • Registered
  • PipPip
  • 39 posts

Posted 20 October 2018 - 08:17 PM

I'm sitting here with my jaw on the floor. I can't believe that this exists! Your write up for installation/configuration was perfect, and I am up and running with amazing new opportunities for automation before me -- now that Home Assistant can see my OmniPro II's entities. THANK YOU so much! Just... incredible.



#29 123

123

    Cocoonut

  • Registered
  • PipPipPipPip
  • 2140 posts
  • Location:Montreal, QC
  • Experience:average
  • Software:Premise
  • Hardware:Elk M1

Posted 21 October 2018 - 10:41 AM

I agree that it should show operating state not mode. That's the one thing Home Assistant is missing as I can't tell when my HVAC system is actually running. I'd be willing to help out with this effort.

Thank you for the detailed GitHub explanation and the offer to help improve MQTT HVAC.

I examined the pull request and it will permit MQTT HVAC to handle operation state thereby allowing the chart to graph when the system is running. It uses a new topic called activity_state_topic. However, upon closer inspection, it has a limitation.

This new activity topic simply wants to know if the HVAC system in active or idle (true/false). So if activity=true and the current operation mode is 'heat' then it concludes the operation state must be 'heat'. If activity=true and mode is 'cool' then state is 'cool'. The charting code knows how to handle heat/cool states so all is well.

Or is it? What if the operation mode is auto? If activity=true and mode is 'auto' then state becomes 'auto' …. and the charting code doesn't know how to handle 'auto'. Therefore, nothing gets charted when state is 'auto' (that's also how the current version of MQTT HVAC behaves; when in auto mode, the chart fails to show a shaded area).

I reported this to the pull request's author and suggested that activity_state_topic should be made smarter than just expecting true/false. Thermostats can report their state in greater detail; at the very least they can report off/heat/cool. The Proliphix thermostat can report something like 5 operating states. Instead of basing the state on the mode, base it on the received activity.

 

The activity must be off/heat/cool and if the thermostat reports in another format (mine reports with integer values) then allow for activity_state_template to convert the received activity and shoehorn it into one of the three acceptable responses.

I received a reply that my observation and suggestion were valid and would be implemented. I noticed today that the pull request's title has reverted to "WIP" (Work In Progress).



#30 TristateUser

TristateUser

    Cocooner

  • Registered
  • PipPip
  • 15 posts
  • Experience:novice
  • Tech:X10-PLC
  • Audio:Russound
  • Video:Custom
  • CCTV:ip

Posted 21 October 2018 - 06:39 PM

OmniLinkBridge is a C# service that allows you to control your OmniPro II controller from SmartThings (Web API) and Home Assistant (MQTT). You can also use it with NodeRed (MQTT) to create flows for advanced control of your devices. As the successor to HAILogger is also provides logging and notifications. You can download and/or contribute on GitHub.

 

Good to see this because I was looking for open-source projects to use and contribute, partly due to my frustration with an HAI Omni LT system that came with the house I purchased recently.  I couldn't use my Omni LT system due to missing so called account files that the previous owner of the house forgot to backup and handover before recycling his laptop that was exclusively used to run PC Access.

 


The big feature for this rewrite is the MQTT module. To get started with Home Assistant you need an MQTT broker such as Mosquitto running and a Windows (.NET Framework 4.5.2) or Linux system (mono) to run OmniLinkBridge. Once configured Home Assistant will auto discover and add the OmniPro II devices.
 

 

I am a newbie; so pardon my ignorance.  I am thinking of upgrading my system because my inherited Omni LT system is pretty much unusable until I figure out a way to get at least PC Access working. Moreover, I want to upgrade it anyway because I don't want to use a dedicated landline/modem-based remote access that Omni LT supports. So what is the minimum system requirement to use OmniLinkBridge (other than some flavor of linux)?  HAI/Leviton OmniPro II?  Can OmniPro II be able to support legacy X10 devices controlled by my [currently unusable] Omni LT system?  Please let me know.  Thank you!






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users