CondorWonder @ CondorWonder @lemmy.ca

Posts

0

Comments

74

Joined

2 yr. ago

Maybe a template sensor over the openweathermap_forecast_condition state? You can pretty easily have a template change its icon, and mdi: has all the icons built in.

Here’s a template I use for current condition in a card, but it should work similarly for the forecast. Or works just need to be applied to the icon of a template sensor.

    
{{ iif(
        is_state("weather.openweathermap", "partlycloudy"), "mdi:weather-partly-cloudy", 
        iif(is_state("weather.openweathermap", "clear-night"), "mdi:weather-night",
        iif(is_state("weather.openweathermap", "exceptional"), "mdi:exclamation-thick",
        "mdi:weather-" + states("weather.openweathermap"
        )))) }}

  

It’s called Badges - edit the dashboard page, then click on the edit button beside the tab.

Possibly - I think Zooz zwave has a toggle switch that could fit, however it will be a different style (and probably not the off-white colour). I don’t know if there’s a wifi that could work.

apropos to search man pages, otherwise I use man

Maybe look at something like a template trigger that checks the last_updated property of the state object? If it’s older than n hours ago it’s triggered?

Why not set up an automation for when it disconnects (goes into unavailable or unknown state probably) and send a notification? That’s relying on the actual problem (Nest goes offline) rather than a side effect of the problem (notification that the integration is broken).

Try executing just /config/backup.sh - the config directory is mapped into the HA container under /config, not under /root.

I’m not sure how consistent it is but the static binaries I have for btrfs-progs are about 2x larger than their dynamic counterparts. If you statically compile it only the functions actually used are included in the binary, so it really depends on how much of the library is used.

Zigbee is a mesh network so it’s a bit different. Zigbee devices can be an end device, or a router device (in addition to whatever it actually does likes controlling a plug). Routers contribute to your zigbee mesh, and devices connect through the mesh. This means you need more router devices to have a strong mesh. I use a few plugs where my network is weak, but otherwise have found that devices are stable. I can’t see on the zigbee2mqtt site if they’re a router or end device, but most powered devices are routers. ZHA and Zigbee2mqtt both tell you the device type if you go digging.

If they’re zigbee devices I don’t think they can be flashed with esphome. They’re not normal esp devices and that would likely disable the zigbee networking.

There is an add on available to help offload backups via SFTP too.

Also check HACS, I’ve seen some weather related integrations there that might work instead.

I don’t use that integration, have you looked at configuration options to see if hourly can be turned on?

If there’s no obvious options it’s likely not supported natively. You could create a restful sensor to retrieve it, just be mindful of api limits.

In general, if you haven’t taken steps to expose your service to the Internet, it’s not accessible over or to the internet. Your router that connects you to the Internet should have a firewall that blocks all inbound, unsolicited requests, and you also need to do something explicit with most self hosted service to expose them, they will not announce themselves to the world.

In addition if you’re using an ipv4 network address that’s likely a private address (like 10.x.y.z, 172.x.y.z, or 192.168.x.y), which also isn’t accessible outside of your network.

The easiest is to create a scene - those are natively exposed in widgets. If you want something that will toggle the light, I’d use an input_boolean in a scene, and an automation that would watch for it changing to on. The automation would toggle the light, then turn the input_boolean off so the scene will do something again.