Thanks @michaeldavie & @shmick, the env_canada==0.0.29 is working well for me. @rlongfield, I am on a PIP install. I wish I new how to have the newer version for the site packages stick without having to fudge PIP in thinking that I am running an older version. When I upgrade the site package after restarting HA it always want to return to its original version so I keep the older PIP information untouched. Maybe someone here knows how to do the upgrade properly.
You can try changing the requirements_all.txt file, which also lists the env_canada version.
You need to change both the manifest.json file for the integration and the requirements_all.txt, as shown in the latest commit:
1 Like
Thanks @michaeldavie, changing the manifest.json did it for me. I do not have a ‘requirements_all.txt’ file, I guess that is a docker requirement? All the best
Thanks @michaeldavie, changing the manifest.json & requirements-all.txt worked. Bumpted env_canada-0.27 to … 0.29.
applied the fix manually and all seems fine now for 101.0.
The fix got merged into 0.101.1 and released today, and it seems to be working correctly on my end. Thanks everyone for your patience and support.
@pg.sylvestre That’s really odd. Are you expecting to see the hourly or the daily forecast? Mine seems to be doing the daily forecast correctly with 0.101.1.
@ michaeldavie The odd mix of daily/hourly has not re-occurred at this time but I see that others got similar results.
My setting are for ‘daily’ and showed correctly on the lovelace card. from what I can gather, the problem was only associated with the “more info” pop-up panel.
You can also calculate your own windchill using the official JAG/TI formula:
jagti_windchill:
value_template: "{{ (13.12 + 0.6215*float(states.sensor.temperature.state) +
0.3965*(float(states.sensor.temperature.state) - 28.676) *
(float(states.sensor.wind_speed.state)*3.6)**0.16) | round(2) }}"
unit_of_measurement: "°C"
friendly_name: Jag/Ti WindchillFWIW, I’m still seeing similar results in the forecast section. Happy to help debug it if I know what I’m looking for.
Cheers.
Hmmm, it just showed up on mine too. I’ll see if I can figure it out.
Update: It seems like this might be an issue with the frontend. The standard card looks right, but the expanded one doesn’t. As far as I can tell my code is returning the right data.
The clue is that it happens when the temperature is 0. Another clue is that it formats the day as if it was an hourly forecast.
Does this line evaluate to false when templow is 0 and thus doesn’t show it? I don’t know typescript, so I can’t really tell too specifically. This fits with all the clues.
Everything seem to be working properly. Though I am attempting to track down errors in my log. Note: that I am an early user of EC, not that it is a bad thing but I might have residual corruption? I attempted to reset all by removing EC from the YAML configuration file and cleaning core.entity_registry file from EC entries but all came back to its original state including the log errors. I am running the PIP release of HA with version env_canada==0.0.29. Any suggestions would be appreciated, here is my log:
Nov 5 15:36:42 services26 scl: Traceback (most recent call last):
Nov 5 15:36:42 services26 scl: File "/var/lib/homeassistant/lib64/python3.6/site-packages/homeassistant/helpers/entity.py", line 273, in async_update_ha_state
Nov 5 15:36:42 services26 scl: self._async_write_ha_state()
Nov 5 15:36:42 services26 scl: File "/var/lib/homeassistant/lib64/python3.6/site-packages/homeassistant/helpers/entity.py", line 307, in _async_write_ha_state
Nov 5 15:36:42 services26 scl: state = self.state
Nov 5 15:36:42 services26 scl: File "/var/lib/homeassistant/lib64/python3.6/site-packages/homeassistant/components/weather/__init__.py", line 188, in state
Nov 5 15:36:42 services26 scl: return self.condition
Nov 5 15:36:42 services26 scl: File "/var/lib/homeassistant/lib64/python3.6/site-packages/homeassistant/components/environment_canada/weather.py", line 157, in condition
Nov 5 15:36:42 services26 scl: if self.ec_data.conditions.get("icon_code").get("value"):
Nov 5 15:36:42 services26 scl: AttributeError: 'NoneType' object has no attribute 'get'#033[0m
This is just me doing bad Python, I’ll try to fix it up for the next release. Just to be sure, are you using a station that doesn’t report current conditions?
Hello @michaeldavie
I access the weather from two sensors/stations and I think they both give you current conditions, if I understand your question properly?
sensor:
- platform: environment_canada
# Chelsea
station: QC/s0000615
- platform: environment_canada
# Ottawa
station: ON/s0000430
Here is some of my states information:
Regards
Anyone else having problems with access to dd.weather.gc.ca??
Can’t seem to be able to get weather data for the last 24 hrs…
UPDATE: Looks like they’ve implemented some kind of Ban System…Issue resolved for now after contacting DPS-Client Support (EC) at [email protected]
Yikes! Did they give you insight into the thresholds?
No insight of any kind yet…guessing they have implemented failtoban or something like that on their debain based system.
.I basically passed on my public ip and it was miraculously back to being available… I have been doing frequent restarts while testing and upgrading…a fail to ban being triggered.would makes sense. Had access to the dd server outside my home network but no access from within even i the ip resolved…
Keep you posted on anything I find out. Support ticket is still open at this point.
.
It stands to reason that they would have a mechanism in place to prevent excessive polling. The weather forecasts and readings don’t change frequently so anyone polling on a shorter interval is placing an unnecessary load on their services.
FWIW, I’ve been using EC’s services for just over a decade. I poll every 30 minutes and, at least for my automation purposes, it’s been sufficient (even for alerts).