⚠ Mise à jour 2022.06.01 ! Attention avant de migrer

Bonjour,

Un petit message préventif avant que vous ne vous lanciez dans la migration : il y a des changements importants et bloquants !!!

Notamment mais pas seulement

:warning: :military_helmet:La section " Breaking Changes" de 2022.6: Gaining new insights! - Home Assistant est à lire … :warning: :military_helmet:

3 « J'aime »

Bonjour j’avoue avoir pris le temps de mes logs et les templates … Vont poser problème si aucune valeur n’est définir par défaut…

[homeassistant.helpers.template] Template warning: 'timestamp_custom' got invalid input '2022-06-02 00:00:00+02:00' when rendering template '{% set format = '%Y-%m-%dT%H:%M:%S+00:00' %} {% set start = now().replace(hour=0,minute=0,second=0, microsecond=0) %} {% set end = (start + timedelta(days=1)) | timestamp_custom(format, false) %} {% set start = start | timestamp_custom(format, false) %} {{ state_attr('weather.ville', 'forecast') | selectattr('datetime', '>=', start) | selectattr('datetime','<=', end) | map(attribute='temperature') | list | max }}' but no default was specified. Currently 'timestamp_custom' will return '2022-06-02 00:00:00+02:00', however this template will fail to render in Home Assistant core 2022.6

Voici l’exemple

Bonjour,

pour ma part, j’ai perdu toutes mes entrées/sorties GPIO de mon PI3.
Mon petit Restore m’a permis de retrouver tout ce petit monde. Oufff :relieved:

C’est dedans aussi


Je vais l’ajouter à la liste

1 « J'aime »

Pour information, il en sera de même pour le 1-Wire sysbus (directement sur le Py ou via Gpio ou I²C),

Mais des spin-off ont été développés, pour les Gpio, il vous faudra utiliser l’intégration:

et pour le 1-Wire sysbus:

PS: les deux sont disponibles via HACS.

Voici quelques changements au niveau base de données:

image

Il y a une nouvelle structure pour les data des events (nouvelle table: events_data) et pour les attributs des entités (nouvelle table state_attributes).

A vous requêtes ! :slight_smile:

Pour ma part la mise à jour de la base de données à l’air particulièrement laborieuse.
Ca va faire + de 12h et ça ne semble toujours pas fini.
Par exemple : HACS n’a toujours pas démarré :

Et quand je force un redémarrage (ce qui n’est peut-être pas une super idée), HA refuse.

Auriez-vous un avis ?

Patience…chez moi ça pris 1o+ min. et après ça j’ai redémaré encore…apres tout était bon

Merci pour le partage :wink:

En fonction du matériel, (cpu/vitesse du support) ça peut varier beaucoup, mais 12h ça me parait particulièrement long.
C’est peut-être l’occasion de vérifier que le contenu en base n’est pas trop important et inutile . Pour 500mo (ce qui est déjà beaucoup) ça m’a pris quelques secondes

Ce que j’ai vu est dans le log…car ça prends du temps , après quelques minutes HA n’essaie plus d’utiliser le recorder et continue a démarer sans (!) recorder mais l’erreur reste. Donc j; ai fait une redemarrage et tout etait bon apres.
EDIT: moi je suis en Docker et mon mariadb dossier est 1,5Gb

J’ai une question, actuellement mon HA tourne sous Docker et a été installé en suivant la doc de @McFly ✅ Installer Home Assistant sur RPi (ou autres SBC), Debian (Méthode Docker & Supervisor).

Quand je vérifie le « Breaking Changes » de la nouvelle version, dans le paragraphe Home Assistant Container, ça me fait un peu peur :scream:
image

En faisant un docker ps, j’obtiens ceci :

Ai-je bien compris que tout container doit être sans commande /init et ce que je vois dans le docker ps m’indique (si j’ai bien compris) que tout mes containers sont avec un /init

Comment dois-je procéder pour corriger le problème ?

Je ne pense pas que ce soit la bonne info que tu visualises.
J’ai moi aussi les « /init » :wink:


Et pourtant ça marche.

Ce que ça veut dire, c’est que si tu crées les containers toi-même, la fonction init est utilisée de base par les images et donc qu’il ne faut pas les surcharger/customiser sous peine de casser le fonctionnement S6 de base. Idem pour les entrypoints

OK, je vais essayer de migrer alors mais :fearful: :cold_sweat: :hot_face:

Avant une sauvegarde complète, au fait est-ce qu’on a une procédure pour remettre une sauvegarde complète en place ?

Tu fais un bête backup de base (la fonction existe dans le core)… ça contient tout
Et tu mets l’archive de coté.
Dans le pire des cas : formatage, installation de Debian (ou équivalent si pi), installation HA et restauration

1 « J'aime »

Entre temps, je suis tombé la dessus en cherchant …

Et tu saurais me dire comment la purger la base ? :slight_smile:

System Health

version core-2022.6.0
installation_type Home Assistant OS
dev false
hassio true
docker true
user root
virtualenv false
python_version 3.9.12
os_name Linux
os_version 5.15.32-v7
arch armv7l
timezone Europe/Paris
Home Assistant Community Store
GitHub API ok
GitHub Content ok
GitHub Web ok
GitHub API Calls Remaining 5000
Installed Version 1.25.5
Stage waiting
Available Repositories 1119
Downloaded Repositories 50
Home Assistant Cloud
logged_in false
can_reach_cert_server ok
can_reach_cloud_auth ok
can_reach_cloud ok
Home Assistant Supervisor
host_os Home Assistant OS 8.1
update_channel stable
supervisor_version supervisor-2022.05.3
agent_version 1.2.1
docker_version 20.10.14
disk_total 109.3 GB
disk_used 12.7 GB
healthy true
supported true
board rpi3
supervisor_api ok
version_api ok
installed_addons File editor (5.3.3), Check Home Assistant configuration (3.10.0), Duck DNS (1.15.0), SSH & Web Terminal (10.1.3), ADB - Android Debug Bridge (0.8.0), Log Viewer (0.13.0), Samba Backup (5.0.0), FTP (4.5.0), Samba share (9.6.1), Z-Wave JS (0.1.60), SomfyProtect2MQTT (0.2.0)
Dashboards
dashboards 1
resources 35
views 14
mode storage
Recorder
error failed to load: unknown
Sonoff
version 3.0.5 (200f243)
cloud_online 0 / 1
local_online 1 / 1

il y a un sujet avec plein d’infos justement

Finalement j’ai forcé un reboot un peu bourrin, puis après très peu de patience, HA a redémarré, a fait la mise à jour rapide de la base de données c’était tout bon !