Weird. I found this, which might help:
Most of that is over my head. Bit of a linux noob here. I did successfully upgrade pip but i didn’t help. I don’t even know where to go to ask for help with this. I don’t think it’s actually a home assistant problem.
Thanks for looking into it though.
You seem to running pip from python2. See last line as well as -I/usr/include/python2.7 in the includes
Try “pip3” or “python3 -m pip” instead if “pip”
OK I just spent a couple hours trying to figure this out… I admit defeat. I’m lost.
If I run pip - V I get
pip 19.0.3 from /usr/lib/python2.7/site-packages/pip (python 2.7)
If I run pip3 I get
command not found: pip3
If I run python3 -m pip I get
command not found: python3
This is all through a terminal window in Cloud9. I eventually figured out I use the normal SSH addon I can run the python3 -m pip command. So I tried installing the env_canada package from there and it does the whole collecting/downloading thing but then fails installing on a completely different element.
I’m sure this has something to do with being in different virtual environments or something like that but damned if I can figure it out. Obviously, this isn’t the place for a crash course in linux.
Thanks for looking at it though @froz
python is python 2.x, and python3 is version 3.x.
Fun note: they are basically not compatible with each other.
From a quick Google, it looks like you can install python3 on Cloud9 with “sudo yum -y install python36”
(as per https://docs.aws.amazon.com/cloud9/latest/user-guide/sample-python.html )
Quick question about Advisory, Statement, Watch, Warning, and Ended sensor values.
I’m still on 0.0.7 (I know, I know) and .88 for HA (ok, I get it) 
I’ve noticed that if there are no alerts out the values have no value.
I had a conditional card that would appear when there was an alert. I used a ‘state_not:’ condition which worked great when the state for the sensor was ‘unknown’. Now with a blank I’m not sure how to handle it. There are too many variables to trigger a conditional card with a state: ‘XX’ condition.
Guess my question is 3 fold, are the sensor still empty values in 0.0.8?
If yes does anyone know how to trigger on a not blank value?
Last is it possible to have a value?
Let me know if I should spin this question out into a separate post.
Yes, this is still the same in 0.0.8. I’m not too familiar with the new UI yet, but have you tried testing whether the state is not an empty string, i.e. ''? If that doesn’t work I could maybe change it to some placeholder, but it seems more Pythonic to leave it blank.
@rlongfield @michaeldavie Here’s how i deal with those sensors to effectively create a “bad weather” sensor. I look at the “hidden” attribute in each sensor to create a binary sensor. In my configuration.yaml:
binary_sensor:
- platform: template
sensors:
bad_weather:
value_template: >-
{{ is_state_attr('sensor.warnings', 'hidden', False) or is_state_attr('sensor.statements', 'hidden', False) or is_state_attr('sensor.advisories', 'hidden', False) or is_state_attr('sensor.watches', 'hidden', False) }}
This lets me display conditional cards when the bad_weather sensor is true.
1 Like
You’ve created a template sensor that does not explicitly indicate the entities that must be monitored for state-changes. As a result, Home Assistant must infer the entities to be monitored by examining the template.
If the entities are non-obvious, Home Assistant will evaluate the template sensor once at startup and never again (i.e. only until the next startup). In addition, Home Assistant will log a warning message indicating the template sensor doesn’t have an obvious entity. Check your log for any messages related to this template sensor.
Should there be a warning message, the solution is to list the entities to be monitored:
binary_sensor:
- platform: template
sensors:
bad_weather:
entity_id:
- sensor.warnings
- sensor.statements
- sensor.advisories
- sensor.watches
value_template: >-
{{ is_state_attr('sensor.warnings', 'hidden', False) or is_state_attr('sensor.statements', 'hidden', False) or is_state_attr('sensor.advisories', 'hidden', False) or is_state_attr('sensor.watches', 'hidden', False) }}
Thank you so much. I was trying a much more complicated way using templates that wasn’t working out. This is so much more elegant and functional.
Conveniently we have a Special weather statement in effect right now so I was able to real world test it and it worked like a charm.
Now if only I could get the card-modder customization to work with a conditional card things would be great!
edit: So I got the card-modder to work, now when there is “bad weather” this beauty pop up.
1 Like
Nice! Could you post your config for this as well?
Absolutely. First off you will need to install card-modder if you haven’t already.
You can find the details on card-modder here: https://github.com/thomasloven/lovelace-card-modder
In ui-lovelace.yaml This bit controls the Weather Alert card.
#Weather Warning Card
- type: conditional
conditions:
- entity: binary_sensor.bad_weather
state: 'on'
card:
type: custom:card-modder
style:
background-color: rgba(251,13,13,1)
border-radius: 5px
--primary-color: white
--paper-item-icon-color: white
card:
type: entities
entities:
- type: weblink
name: Weather Alert
icon: mdi:weather-lightning-rainy
url: https://weather.gc.ca/warnings/report_e.html?XX##
Make sure to change XX## to your location code. Clicking the link will open the weather advisory page for the XX## location in a new browser tab.
This bit creates the binary_sensor.bad_weather used in the conditional card above courtesy of @davidbb and @123:
If you are putting this in your configuration.yaml it will go under the
binary_sensor:
I put it in a binary_sensors.yaml file with:
binary_sensor: !include binary_sensors.yaml
#Creating a Bad Weather Binary Sensor for warning card
- platform: template
sensors:
bad_weather:
entity_id:
- sensor.warnings
- sensor.statements
- sensor.advisories
- sensor.watches
value_template: >-
{{ is_state_attr('sensor.warnings', 'hidden', False) or is_state_attr('sensor.statements', 'hidden', False) or is_state_attr('sensor.advisories', 'hidden', False) or is_state_attr('sensor.watches', 'hidden', False) }}
That’s pretty much it.
1 Like
Put three backticks (```) on their own line before and after the code to be formatted.
That works for me (proof is the formatted code in my previous post). It’s just one of the many ways to use markdown to format text.
I offer a small refinement to the bad_weather template binary sensor.
In this example, value_template is substantially streamlined because it operates on the assumption that the EnviroCan-related sensors (warnings, statements, advisories, watches) are the only sensors to have an attribute called hidden (which is generally true; hidden is a custom attribute).
#binary_sensor:
- platform: template
sensors:
bad_weather:
entity_id:
- sensor.warnings
- sensor.statements
- sensor.advisories
- sensor.watches
value_template: >-
{{ true if states.sensor | selectattr('attributes.hidden', 'eq', false) | list | count > 0 else false }}
The template works like this:
- It gets all sensors and selects the ones with
hidden=false. - It transforms the result into a list then counts the numbers of items in the list.
- If the count is greater than zero then the result is
true, otherwise it’sfalse.
FWIW, this same technique is often used to determine the number of lights currently on (it checks the entity’s state as opposed to an attribute).
If you have other sensors with the hidden attribute then this template requires a small revision (and requires you create a group containing the EnviroCan sensors). Let me know if this happens to be the case for you and I’ll provide you with an enhanced template.
In lieu of a template binary sensor you can easily trim the value_template to create a template sensor that reports the number of concurrent alerts (numeric value from 0 to 4). Once again, this template assumes you have no other sensors with an attribute called hidden.
#sensor:
- platform: template
sensors:
bad_weather:
entity_id:
- sensor.warnings
- sensor.statements
- sensor.advisories
- sensor.watches
value_template: >-
{{ states.sensor | selectattr('attributes.hidden', 'eq', false) | list | count }}
1 Like
Thanks, this is great! I should point out though that I use the hidden attribute for all of the Environment Canada sensors, and it gets flipped to true whenever there isn’t a value present in the data, e.g. for windchill or humidex.
@123 the problem with both of your alternatives is that they grab hidden attributes for all sensors in your HA installation, not just the ones exposed for the custom component. As @michaeldavie says, there are more sensors in the custom component that use those attributes so users could run into issues if they copy and paste your config into theirs.
FWIW HA does not throw warnings for me when I don’t explicitly list the entity ids. This is because in my original bad_weather binary sensor the relevant sensors are listed in the template. Keeps my configuration.yaml a bit tidier. Your suggested improvements definitely need explicit declaration of entity ids.
My post explained it works that way and that it’s a potential limitation if other sensors use the hidden attribute. Michael then confirmed other sensors do use hidden so the solution won’t work as desired (i.e. it won’t limit itself to just the advisories, warnings, statements, and watches sensors).
What I originally offered hinged on this statement:
Should there be a warning message, the solution is to list the entities to be monitored:
You’ve confirmed there is no warning message (thank you) so, as you’ve stated, there’s no need to explicitly identify the entities to be monitored. In this case, Home Assistant is able to identify them automatically within the template (but there are situations when it cannot).
The following version of the bad_weather template binary sensor restricts itself to the four sensors and is compact.
- platform: template
sensors:
bad_weather:
value_template: >-
{% set alerts = [state_attr('sensor.advisories', 'hidden'),
state_attr('sensor.statements', 'hidden'),
state_attr('sensor.watches', 'hidden'),
state_attr('sensor.warnings', 'hidden')] %}
{{ alerts | select('==', false) | list | count > 0 }}
Should one wish to convert it into a sensor, that reports a value from 0 to 4, the template is easily modified (as explained in my previous post).
Question for all, after you restart Home Assistant do the sensor’s maintain their attribute values?
For example, if hidden=false for sensor.warnings, does it maintain that after a restart?
In my experience with MQTT sensors, custom attributes are lost after a restart.
Yes and no. The sensors don’t save their state or attributes, but they’re refreshed whenever a sensor is updated, including on startup. Specifically, the hidden attribute is set to True if there isn’t any data for that particular sensor after an update. If you’re curious, I’ve linked to the code below.
Good evening,
I’ve been following this thread sporadically for some time. Amazing progress!
May I ask if you have any info on when your component will be released “officially” or do you believe it is better to do a custom install?
Thank you.