The email on alarm works, but it looks like I had removed the service start and stop emails. I'm restructuring the code so the different components are now modular driven by events. Additionally I'm swapping over to log4net for file logging. I'm going to rewrite the notifications for Email, Prowl, and add Pushover. I'm only planning to do alarm notifications. Once the data is in MQTT you can create custom notifications with whatever third party tool you'd like. I don't think custom notifications inside HAILogger make sense without adding some sort of rules engine.
HomeSeer 3 and openHAB
- Thread starter rsw686
- Start date
pete_c
Guru
Thank you Ryan and understood.
Yeah here the HAILogger program is installed on a Pine64 running Ubuntu server / most current version of Mono. Email is going though STunnel on the same box. Using STunnel for other boxes and texting / mail services. Working fine. Updated OP2 firmware a while ago to current release. I do remember seeing stopping and starting services thing. Not using mySQL with it at this time. Only see an occasional time sync text / email or an occassional Samsung Smartthings disconnect text or email. Just wondering then if it is a Mono 5.12 thing.
Looking forward to your Mosquitto stuff.
Here starting to (baby steps) forward Homeseer variables (including OP2 stuff) to Mosquitto broker.
Been also tinkering here with opensource Domoticz which has now incorporated Mosquitto. The opensource program is a little bit of this and that (python, LUA, et al). Seeing too that many of the Tasmota firmware modes are Domoticz specific. (OpenHab, Home Assistant and Domoticz are becoming mainstream opensource).
Yeah here the HAILogger program is installed on a Pine64 running Ubuntu server / most current version of Mono. Email is going though STunnel on the same box. Using STunnel for other boxes and texting / mail services. Working fine. Updated OP2 firmware a while ago to current release. I do remember seeing stopping and starting services thing. Not using mySQL with it at this time. Only see an occasional time sync text / email or an occassional Samsung Smartthings disconnect text or email. Just wondering then if it is a Mono 5.12 thing.
Looking forward to your Mosquitto stuff.
Here starting to (baby steps) forward Homeseer variables (including OP2 stuff) to Mosquitto broker.
Been also tinkering here with opensource Domoticz which has now incorporated Mosquitto. The opensource program is a little bit of this and that (python, LUA, et al). Seeing too that many of the Tasmota firmware modes are Domoticz specific. (OpenHab, Home Assistant and Domoticz are becoming mainstream opensource).
Fyi, you can do the home and shop under OpenHAB as that's what I have. I have one vera plus in my house and one in my shop building as my zwave controllers. OpenHAB talks to them over ethernet and handles all the rules and everything else for my home system. The Veras work good in this manner as they're just a zwave interface and they work well with openHAB. I've been running this way for 3 years now.
Danny
Danny
<p>I finally got around to rewriting HAILogger and building in the MQTT bridge code. I have the zones and units auto populating in Home Assistant using MQTT discovery. I plan to get the area and thermostats done as well before I release it. The only thing I don't like is Home Assistant appears to only have a single temperature set point for their HVAC even when in auto mode. The OmniStat 2 has a cool and heat setpoint so I'm debating how to handle it.</p>
Good news! I have my rewrite of HAILogger, which is called OmniLinkBridge, working with MQTT and Home Assistant. Right now I have support for area status and arming, zone status, unit status and control, thermostat status and control, and button control. It's enough functionality to get basic use out of the system through Home Assistant. I built out the discovery part as well so they just appear on as new devices in Home Assistant. I had to extend the climate and alarm_control_panel component in Home Assistant. I'm planning to submit a git pull request and hopefully they will include the changes. I need to finish up some documentation and then I plan to start a new thread with all the details.The SmartThings integration is still intact so running OmniLinkBridge gives you both functionality.
Also if you have a Lowes AO Smith water heater with the energy smart module I put together a separate EnergySmartBridge to report it's status into MQTT. This required adding a DNS override for https://energysmartwaterheater.com on my router, which redirects to a local nginx reverse proxy that provides the SSL offload, which then goes to my C# service, which publishes to MQTT for Home Assistant. Slightly round about but it works. The energy smart module is really picky about the SSL handshake. I can't figure out how to tell mono not to request a client certificate and this causes the handshake to fail, which is where nginx comes in. Additionally the module appears to only support sha1 certificates. I emailed AO Smith and am waiting to hear back on the format to change the mode and setpoint from Home Assistant.
Also if you have a Lowes AO Smith water heater with the energy smart module I put together a separate EnergySmartBridge to report it's status into MQTT. This required adding a DNS override for https://energysmartwaterheater.com on my router, which redirects to a local nginx reverse proxy that provides the SSL offload, which then goes to my C# service, which publishes to MQTT for Home Assistant. Slightly round about but it works. The energy smart module is really picky about the SSL handshake. I can't figure out how to tell mono not to request a client certificate and this causes the handshake to fail, which is where nginx comes in. Additionally the module appears to only support sha1 certificates. I emailed AO Smith and am waiting to hear back on the format to change the mode and setpoint from Home Assistant.
pete_c
Guru
Good news Ryan!!!
Will the OmniLinkBridge run as the HAILogger in Linux with current release of Mono?
Last release of your HAILogger program is running on Ubuntu 18.04 64 bit on a Pine64 with Mono installed.
The Rock64 4Gb computer is small and will fit inside of the OmniPro 2 can. I plan to add another ethernet interface to it such that it acts as a router plus HA interface to the OmniPro 2.
Ideally it would be nice if it didn't need to run in Mono such that I could run the interface on a micro OpenWRT router. I have mosquitto running fine using python on the OpenWRT router.
Will the OmniLinkBridge run as the HAILogger in Linux with current release of Mono?
Last release of your HAILogger program is running on Ubuntu 18.04 64 bit on a Pine64 with Mono installed.
The Rock64 4Gb computer is small and will fit inside of the OmniPro 2 can. I plan to add another ethernet interface to it such that it acts as a router plus HA interface to the OmniPro 2.
Ideally it would be nice if it didn't need to run in Mono such that I could run the interface on a micro OpenWRT router. I have mosquitto running fine using python on the OpenWRT router.
Still working on getting it all wrapped up to release. I have pull requests in with Home Assistant for the MQTT support.
https://github.com/home-assistant/home-assistant/pull/17390
https://github.com/home-assistant/home-assistant/pull/17391
https://github.com/home-assistant/home-assistant/pull/17390
https://github.com/home-assistant/home-assistant/pull/17391
For those following here OmniLinkBridge is available and I started a new thread with details.
123
Senior Member
@rsw686
Given that you've submitted a pull request for MQTT HVAC, I'm going to assume you know its source code far better than I do and can answer this question:
Why isn't it using "temp_step"?
In the code there's "temp_step". It's ostensibly the setpoint temperature's step-size. By default it's 1 which is fine when you're adjusting the setpoint in Fahrenheit but not for Celsius (ought be 0.5). Whereas "max_temp" and "min_temp" are documented (max and min settings for setpoint range) "temp_step" is not. Ignoring that, I added "temp_step: 0.5" to configuration.yaml and, in turn, Home Assistant ignored it and continued to use a step-size of one.
I looked at the OpenTherm component's documentation and code and it uses the term "precision" to specify the step-size. I compared it to MQTT HVAC's code but I can't quite pin down why "temp_step" isn't processed. My best guess is that it is not being read from configuration.yaml because it's missing from this line (but I wouldn't bet any money on it):
Line 14 says:
from homeassistant.components.climate import ( STATE_HEAT, STATE_COOL, STATE_DRY, STATE_FAN_ONLY, ClimateDevice, PLATFORM_SCHEMA as CLIMATE_PLATFORM_SCHEMA, STATE_AUTO, ATTR_OPERATION_MODE, SUPPORT_TARGET_TEMPERATURE, SUPPORT_OPERATION_MODE, SUPPORT_SWING_MODE, SUPPORT_FAN_MODE, SUPPORT_AWAY_MODE, SUPPORT_HOLD_MODE, SUPPORT_AUX_HEAT, DEFAULT_MIN_TEMP, DEFAULT_MAX_TEMP)
I see min_temp and max_temp but no temp_step.
Way down around line 129, I see it hard-codes temp_step to 1 rather than from a value recorded in configuration.yaml.
vol.Optional(CONF_MIN_TEMP, default=DEFAULT_MIN_TEMP): vol.Coerce(float),
vol.Optional(CONF_MAX_TEMP, default=DEFAULT_MAX_TEMP): vol.Coerce(float),
vol.Optional(CONF_TEMP_STEP, default=1.0): vol.Coerce(float)
If you can shed any light I would appreciate it.
In addition, (obvious newbie question coming up) where the heck does Home Assistant store the components it uses? I'd like to take a copy of MQTT HVAC's code from github, put it on my HA server, and experiment with it. However, I don't know where to place the code so HA uses it instead of the release version.
EDIT
Found it!
\\wadever\HASS-Config\lib\python3.6\site-packages\homeassistant\components\climate
Given that you've submitted a pull request for MQTT HVAC, I'm going to assume you know its source code far better than I do and can answer this question:
Why isn't it using "temp_step"?
In the code there's "temp_step". It's ostensibly the setpoint temperature's step-size. By default it's 1 which is fine when you're adjusting the setpoint in Fahrenheit but not for Celsius (ought be 0.5). Whereas "max_temp" and "min_temp" are documented (max and min settings for setpoint range) "temp_step" is not. Ignoring that, I added "temp_step: 0.5" to configuration.yaml and, in turn, Home Assistant ignored it and continued to use a step-size of one.
I looked at the OpenTherm component's documentation and code and it uses the term "precision" to specify the step-size. I compared it to MQTT HVAC's code but I can't quite pin down why "temp_step" isn't processed. My best guess is that it is not being read from configuration.yaml because it's missing from this line (but I wouldn't bet any money on it):
Line 14 says:
from homeassistant.components.climate import ( STATE_HEAT, STATE_COOL, STATE_DRY, STATE_FAN_ONLY, ClimateDevice, PLATFORM_SCHEMA as CLIMATE_PLATFORM_SCHEMA, STATE_AUTO, ATTR_OPERATION_MODE, SUPPORT_TARGET_TEMPERATURE, SUPPORT_OPERATION_MODE, SUPPORT_SWING_MODE, SUPPORT_FAN_MODE, SUPPORT_AWAY_MODE, SUPPORT_HOLD_MODE, SUPPORT_AUX_HEAT, DEFAULT_MIN_TEMP, DEFAULT_MAX_TEMP)
I see min_temp and max_temp but no temp_step.
Way down around line 129, I see it hard-codes temp_step to 1 rather than from a value recorded in configuration.yaml.
vol.Optional(CONF_MIN_TEMP, default=DEFAULT_MIN_TEMP): vol.Coerce(float),
vol.Optional(CONF_MAX_TEMP, default=DEFAULT_MAX_TEMP): vol.Coerce(float),
vol.Optional(CONF_TEMP_STEP, default=1.0): vol.Coerce(float)
If you can shed any light I would appreciate it.
In addition, (obvious newbie question coming up) where the heck does Home Assistant store the components it uses? I'd like to take a copy of MQTT HVAC's code from github, put it on my HA server, and experiment with it. However, I don't know where to place the code so HA uses it instead of the release version.
EDIT
Found it!
\\wadever\HASS-Config\lib\python3.6\site-packages\homeassistant\components\climate
@123
I actually don't know the MQTT HVAC code that well. My original intention wasn't to have to modify it. However having only one setpoint wasn't going to work for me. I'm not sure about the temp set issue. Mine is set to F so the up and down arrows move it by 1 degree.
For overriding the components to test, you want to put them in config/custom_components. For example the climate mqtt would go in config/custom_components/climate/mqtt.py
I actually don't know the MQTT HVAC code that well. My original intention wasn't to have to modify it. However having only one setpoint wasn't going to work for me. I'm not sure about the temp set issue. Mine is set to F so the up and down arrows move it by 1 degree.
For overriding the components to test, you want to put them in config/custom_components. For example the climate mqtt would go in config/custom_components/climate/mqtt.py
123
Senior Member
OK, thanks!
Before knowing about config/custom_components/climate, I went ahead and just made an mqttnew.py file in site-packages/homeassistant/components/climate. I realize that's bad form (and will move it out of there) but it let me move to the next step, namely modifying the code.
FWIW, I borrowed the approach used in OpenTherm Gateway. It checks the unit-system Home Assistant is configured to use. If imperial than it sets the step-size to a system constant called PRECISION_WHOLE. If the unit system is metric then the step-size is set to PRECISION_HALVES. If the user entered a value for "precision" in configuration.yaml, then that's used instead. Simple.
I won't say it went swimmingly. This is the first time I've ever touched Python let alone the code in an HA component. It took several revisions before Home Assistant stopped complaining about my modifications. Anyway, it now effectively auto-configures itself and the setpoint temperature can be set in 0.5 degree increments like all good metric thermostats should.
If I ever find the time, I'll learn how to get onto GitHub and submit a pull request.
Before knowing about config/custom_components/climate, I went ahead and just made an mqttnew.py file in site-packages/homeassistant/components/climate. I realize that's bad form (and will move it out of there) but it let me move to the next step, namely modifying the code.
FWIW, I borrowed the approach used in OpenTherm Gateway. It checks the unit-system Home Assistant is configured to use. If imperial than it sets the step-size to a system constant called PRECISION_WHOLE. If the unit system is metric then the step-size is set to PRECISION_HALVES. If the user entered a value for "precision" in configuration.yaml, then that's used instead. Simple.
I won't say it went swimmingly. This is the first time I've ever touched Python let alone the code in an HA component. It took several revisions before Home Assistant stopped complaining about my modifications. Anyway, it now effectively auto-configures itself and the setpoint temperature can be set in 0.5 degree increments like all good metric thermostats should.
If I ever find the time, I'll learn how to get onto GitHub and submit a pull request.
KennethZew
New Member
using KM8.19
URC9910 and RS15-2117
Simple.txt loads and performs fine.
neither Hacked or Home-Automation will load- error is File does not appear to be a valid Device Upgrade ...
AND, I am new to getting into X10 and just want to control a few lamps. What do the Hacked and Home-Automation upgrades give me? Can I get a way with SImple? Do I need any of these?
thanks much
URC9910 and RS15-2117
Simple.txt loads and performs fine.
neither Hacked or Home-Automation will load- error is File does not appear to be a valid Device Upgrade ...
AND, I am new to getting into X10 and just want to control a few lamps. What do the Hacked and Home-Automation upgrades give me? Can I get a way with SImple? Do I need any of these?
thanks much
Similar threads
