MSR UI on a mobile browser

[tamorgen]

Good morning,
So Home Assistant decided to change the default weather home format that I've been using for the past year and a half. I had two Global Expressions set up to pull the high and low temp forecast for the day. Now it's pulling null values.

In the dev tools, it now uses a new service (Weather. get forecasts), plural, where the old Weather.get forecast is depreciated and now longer functions.

It shows a templow field, and a temperature field, which I presume is the forecast high.

When I head back over to MSR, I'm having a hard time finding those values in the Entities tab.

wx.asoftime=null
wx.ceiling=null
wx.ceiling_unit=null
wx.cloud_cover=null
wx.condition_code=null
wx.description="partlycloudy"
wx.feels_like=null
wx.humidity=57
wx.humidity_unit="%"
wx.icon=null
wx.location=null
wx.precipitation_1hr=null
wx.precipitation_24hr=null
wx.precipitation_other=null
wx.precipitation_type=null
wx.precipitation_unit="in"
wx.pressure=30
wx.pressure_unit="inHg"
wx.temperature=55
wx.temperature_unit="°F"
wx.visibility=null
wx.visibility_unit="mi"
wx.wind_compass=210.3
wx.wind_conditions=null
wx.wind_direction="SSW"
wx.wind_gust=null
wx.wind_speed=6.28
wx.wind_speed_unit="mph"
x_hass.domain="weather"
x_hass.entity_id="weather.forecast_home"
x_hass.services=["weather"]
x_hass.state="partlycloudy"
x_hass_attr.attribution="Weather forecast from met.no, delivered by the Norwegian Meteorological Institute."
x_hass_attr.cloud_coverage=85.9
x_hass_attr.dew_point=40
x_hass_attr.friendly_name="New Windsor Weather"
x_hass_attr.humidity=57
x_hass_attr.precipitation_unit="in"
x_hass_attr.pressure=30
x_hass_attr.pressure_unit="inHg"
x_hass_attr.supported_features=3
x_hass_attr.temperature=55
x_hass_attr.temperature_unit="°F"
x_hass_attr.visibility_unit="mi"
x_hass_attr.wind_bearing=210.3
x_hass_attr.wind_speed=6.28
x_hass_attr.wind_speed_unit="mph"

There is a x_hass_attr.temperature, but that appears to be the current temperature, not the high that I found on the dev tools screenshot.

Any ideas?

Running:

Core
2024.4.3
Supervisor
2024.04.0
Operating System
12.2
Frontend
20240404.2

MSR: latest-24057-e9add9f5

[toggledbits]

Chalk it up to Home Assistant's legacy of breaking changes. The whole matter of service calls being able to return data came about in 2023.7 but didn't work until 2023.12 for the websocket API, and didn't apply to anything anyone seemed to care about until now. So current Reactor doesn't store that response anywhere, and in fact doesn't know to ask for it, and the service you're calling requires it, so you're probably getting an error in the log that you haven't spotted (always look at the logs when things don't work as expected!).

Until I get a fix for this into HassController, the only remedy right now is to downgrade your Hass back to 2024.3 or earlier.

P.S. This is why I say in the documentation and have HassController complain bitterly when you're running a Hass version that isn't yet supported/verified. I assume you got a warning about that, too.

[tamorgen]

@toggledbits said in HomeAsssistant Weather changed.... Global expression no longer functioning:

Chalk it up to Home Assistant's legacy of breaking changes. The whole matter of service calls being able to return data came about in 2023.7 but didn't work until 2023.12 for the websocket API, and didn't apply to anything anyone seemed to care about until now. So current Reactor doesn't store that response anywhere, and in fact doesn't know to ask for it, and the service you're calling requires it, so you're probably getting an error in the log that you haven't spotted (always look at the logs when things don't work as expected!).

Until I get a fix for this into HassController, the only remedy right now is to downgrade your Hass back to 2024.3 or earlier.

P.S. This is why I say in the documentation and have HassController complain bitterly when you're running a Hass version that isn't yet supported/verified. I assume you got a warning about that, too.

Thanks Patrick, that's pretty much what I had figured. It wouldn't be the first time that HAAS has changed something 6 months ago and broke my setup.

I did see the notice yes, however, I think there was another notice I got from HAAS that told me if I didn't upgrade that something else would stop functioning. Always a balancing act unfortunatley.

Let me know when you come out with a version of HaasController that addresses this, and I'll gladly test it out for you.

[therealdb]

I had the same problem and moved to a rule with openweathermap.

I capture the response in a global variable and use it in my automation. I even have a couple of virtual devices to remap it. Less dependent on HASS and OWM has better forecast for me. Free API keys if you make two separate calls for current and forecast.

[tamorgen]

@therealdb said in HomeAsssistant Weather changed.... Global expression no longer functioning:

I had the same problem and moved to a rule with openweathermap.

I capture the response in a global variable and use it in my automation. I even have a couple of virtual devices to remap it. Less dependent on HASS and OWM has better forecast for me. Free API keys if you make two separate calls for current and forecast.

I tried that, and you're right, in theory it should work, however, OWM shows "null" for forecast low for me.

[toggledbits]

@tamorgen are you installed bare-metal, or running in docker?

[gwp1]

@tamorgen I've used OWM and VisualCrossing as well as pulling data in via local API from my Ambient and Tempest weather arrays in the backyard.

OWM is currently in the middle of changing to v3.0 of their All-in-One API, fyi. This may/may not affect you.

[toggledbits]

Service responses are addressed in build 24115 (just released)

[therealdb]

@tamorgen try cnt param or similar to limit the response size.

[therealdb]

it's cnt. Since I just want the next forecast, I'm limiting it to 5.

https://api.openweathermap.org/data/2.5/forecast?lat=X&lon=X&units=metric&appid=X&lang=en&cnt=5

@gwp1 is right, but if you don't want to use onecall (very helpful to be honest) and want to make two calls, you'll be good with the free one. As I said, I just want forecast (for cloud, rain and min/max temp), so it's just one call for me.

Initially I wanted to make a dedicated controller for OWM (using the native weather station capability), but it's just one call, so it's easier this way.

[tamorgen]

@toggledbits

I'm installed bare-metal.

[tamorgen]

So it does appear to call the service now. Now I have to figure out how to get it into my expression.

This output was from going into the Entities tab, and running the service manually. If I want to get the forecast and get the high/low temps, will i need to run an action daily to call the service, or will the expression do it for me? I don't see any documentation yet on the Reactor installation instructions for Service responses.

wx.asoftime=null
wx.ceiling=null
wx.ceiling_unit=null
wx.cloud_cover=null
wx.condition_code=null
wx.description="cloudy"
wx.feels_like=null
wx.humidity=60
wx.humidity_unit="%"
wx.icon=null
wx.location=null
wx.precipitation_1hr=null
wx.precipitation_24hr=null
wx.precipitation_other=null
wx.precipitation_type=null
wx.precipitation_unit="in"
wx.pressure=30.26
wx.pressure_unit="inHg"
wx.temperature=41
wx.temperature_unit="°F"
wx.visibility=null
wx.visibility_unit="mi"
wx.wind_compass=13.7
wx.wind_conditions=null
wx.wind_direction="N"
wx.wind_gust=null
wx.wind_speed=8.26
wx.wind_speed_unit="mph"
x_hass.domain="weather"
x_hass.entity_id="weather.forecast_home"
x_hass.services=["weather"]
x_hass.state="cloudy"
x_hass_attr.attribution="Weather forecast from met.no, delivered by the Norwegian Meteorological Institute."
x_hass_attr.cloud_coverage=89.8
x_hass_attr.dew_point=28
x_hass_attr.friendly_name="New Windsor Weather"
x_hass_attr.humidity=60
x_hass_attr.precipitation_unit="in"
x_hass_attr.pressure=30.26
x_hass_attr.pressure_unit="inHg"
x_hass_attr.supported_features=3
x_hass_attr.temperature=41
x_hass_attr.temperature_unit="°F"
x_hass_attr.visibility_unit="mi"
x_hass_attr.wind_bearing=13.7
x_hass_attr.wind_speed=8.26
x_hass_attr.wind_speed_unit="mph"
x_hass.last_response={"service":"weather.get_forecasts","since":1714043894115,"response":{"weather.forecast_home":{"forecast":[{"condition":"partlycloudy","datetime":"2024-04-25T16:00:00+00:00","wind_bearing":24,"temperature":57,"templow":41,"wind_speed":8.26,"precipitation":0,"humidity":51},{"condition":"sunny","datetime":"2024-04-26T16:00:00+00:00","wind_bearing":130.1,"temperature":61,"templow":41,"wind_speed":10.5,"precipitation":0,"humidity":30},{"condition":"cloudy","datetime":"2024-04-27T16:00:00+00:00","wind_bearing":142.8,"temperature":56,"templow":42,"wind_speed":10.31,"precipitation":0,"humidity":59},{"condition":"sunny","datetime":"2024-04-28T16:00:00+00:00","wind_bearing":234.2,"temperature":78,"templow":47,"wind_speed":7.15,"precipitation":0,"humidity":49},{"condition":"partlycloudy","datetime":"2024-04-29T16:00:00+00:00","wind_bearing":239.6,"temperature":86,"templow":62,"wind_speed":6.28,"precipitation":0,"humidity":42},{"condition":"cloudy","datetime":"2024-04-30T16:00:00+00:00","wind_bearing":257.4,"temperature":85,"templow":67,"wind_speed":8.08,"precipitation":0.02,"humidity":39}]}}}

My call was for daily, so it shows a forecast for 5 days. Somehow I need to distinguish just today's forecast.

[toggledbits]

The response is stored on the target Reactor entity (that's entity from which you make the service call, unless you are using call_service from the system entity, in which case you have to specify a target). The x_hass.last_response attribute is used to store the returned response. It is not processed in any way, it is stored as it is received (so it will always be a string).

I think the rest of the work is pretty much the same as how you'd handle a response from an HTTP request, and you've probably done it all before, but I'll spell it out for the benefit of other future readers.

If you copy-paste the response into a beautifier like jsonlint.com it will pretty-print the object so it's easier to discern its structure. The forecast lives in an array called forecast, and the array seems to have the current day's forecast as the first element (i.e. it's sorted by date, ascending). An unfortunate choice on the API's part is that they chose to name a key in their response weather.forecast_home — the dot in the key name will make it just a little harder to navigate through the object, because dot is a special syntax character in the expression language for accessing elements in object. We'll have to use an alternate syntax, which I'll illustrate with the example expression below that brings everything together up to this point. I break it into two parts to keep it more readable and easy to follow:

r = getEntity( 'entity-canonical-id' ).attributes.x_hass.last_response,
forecast_today = r.response['weather.forecast_home'].forecast[0]

Although this is two lines, it is implemented in one (probably global) expression. In the first line, we use an expression local variable r to fetch the response data from the entity. In the second line, we traverse the data in r to get to the forecast data. We use ['name'] syntax instead of .name syntax to access the property with key weather.forecast_home. The [0] at the end simply gets the first element (they are numbered from 0 in our expression language) of the forecast array.

At this point, the expression result would be an object containing the first forecast. You can add a further line to this expression to return one value from the forecast if you only need one, or create multiple new expressions that use the result of this expression if you need more than one value.

condition = forecast_today.condition
templow = forecast_today.tempLow

Overall, I'd make one rule to periodically call the service and fetch the weather, with whatever frequency suits you (i.e. it only does the fetch). I'd make forecast_today above a global expression. The parts of the forecast you need could be drawn out from forecast_today using other global expressions or in rule expressions. When the query rule causes an update to x_hass.last_response, the engine will re-evaluate the forecast_today expression to parse the result to the single forecast object. Other expression evaluations will be triggered by a change in that object, and that, of course, will cause evaluation of rules' triggers that involve those variables.

[tamorgen]

Looks like I may be missing something....

I tried it as you showed it, putting my cannonical ID in place.

It's giving me a response error "Last value: (error) Unexpected token o in JSON at position 1"

I then tried splitting up the lines, but that doesn't seem to work either.

It's giving me an error about an unexpected token o in JSON at position 1 as well, however, for the second one, it gives me "Last value: (error) Invalid scope in reference to member response of (object)null". I suspect the first method is the correct one, but I must have something incorrect in the format.

[toggledbits]

My bad. Looks like it does return a real object, and it doesn't need to be parsed. Remove the parseJSON() call. I'll fix up the earlier post.

[tamorgen]

Awesome, that did the trick!