Mon problème
Bonsoir,
Je vous contacte car j’ai eu un Kernel panic sur mon PI hébergeant mon HA Supervised stocké sur SSD.
J’ai donc repris ma carte SD où j’avais sauvegardé un HA supervised avec une version de Janvier et j’ai ensuite chargé chargé un snapshot de fin Avril (mon intention étant une fois fonctionnel de retransférer tout cela sur SSD). Mais je constate qu’il y a des soucis :
- j’ai dû réinstaller malgré tous les add-ons HACS et modules complémentaires
- mais le plus étranges est que l’app HA smartphone commence tout juste à s’ouvrir avant d’afficher l’écran ci-dessous; étant possesseur du https, je force donc l’app à continuer, mais il se ferme tout de suite après
Savez-vous ce qui ne va pas, ce qu’il faudrait que je fasse pour débloquer la protection sur mon app HA smartphone ? à noter que j’ai le même message si je tape l’adresse https sur mon PC ou smartphone, et ça passe en forçant à consulter malgré tout ce site, il est juste écrit « dangereux » devant « htpps://xxxx.duckdns.org:8123/yyy »
- je constate également que mon Samba share est instable et se délogue après quelques minutes
Je remarque enfin que je retrouve des erreurs que je n’avais plus eu après un fresh install (network manager, system…) :
Ma configuration
[center]## System Information
| version |
core-2023.5.2 |
| installation_type |
Home Assistant Supervised |
| dev |
false |
| hassio |
true |
| docker |
true |
| user |
root |
| virtualenv |
false |
| python_version |
3.10.11 |
| os_name |
Linux |
| os_version |
5.15.74-v7l+ |
| arch |
armv7l |
| timezone |
Europe/Paris |
| config_dir |
/config |
Home Assistant Community Store
| GitHub API |
ok |
| GitHub Content |
ok |
| GitHub Web |
ok |
| GitHub API Calls Remaining |
4982 |
| Installed Version |
1.32.1 |
| Stage |
running |
| Available Repositories |
1367 |
| Downloaded Repositories |
59 |
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 |
Raspbian GNU/Linux 11 (bullseye) |
| update_channel |
stable |
| supervisor_version |
supervisor-2023.04.1 |
| agent_version |
1.4.1 |
| docker_version |
20.10.21 |
| disk_total |
28.9 GB |
| disk_used |
17.9 GB |
| healthy |
true |
| supported |
failed to load: Unsupported |
| supervisor_api |
ok |
| version_api |
ok |
| installed_addons |
Duck DNS (1.15.0), ESPHome (1.16.2), Eufy Security Add-on (1.3.0), File editor (5.6.0), Home Assistant Google Drive Backup (0.110.4), Mosquitto broker (6.2.1), RTSP Simple Server Add-on (v0.17.6), Samba Backup (5.2.0), Samba share (10.0.1), Terminal & SSH (9.7.0), Zigbee2MQTT (1.30.4-1), EnOcean MQTT (0.1.21), Frigate (Full Access) (0.12.0), Samba share with interfaces configuration (10.0.0.3) |
Dashboards
| dashboards |
1 |
| resources |
39 |
| views |
15 |
| mode |
storage |
Recorder
| oldest_recorder_run |
5 mai 2023 à 13:58 |
| current_recorder_run |
6 mai 2023 à 21:36 |
| estimated_db_size |
220.62 MiB |
| database_engine |
sqlite |
| database_version |
3.40.1 |
Spotify
| api_endpoint_reachable |
ok |
[/center]
Comment récupérer ma configuration :
Dans votre HA, Menu latéral `Paramètres` > `Système` > `Corrections` puis les trois petits points en haut a droite > `Informations Système` puis une fois en bas `Copier`
___
Je me réponds à moi-même pour la première partie du problème, l’histoire du site « dangereux » et de l’app Smartphone inopérationnelle provenait du fait que j’avais refermé le port 80 à mon HA.
Par contre, j’ai toujours :
Salut
J’y vais de ma petite hypothèse…
- En partant du principe que tu utilisais l’adresse ip ET un certificat https, on rentre dans le cas bien connu où le navigateur râle parce que le https se base sur un nom de domaine et pas une ip…
Du coup, en ouvrant le port 80 et avec l’adresse ip, il n’y a pas ce genre de contrôle. Mais par contre il n’y a pas de sécurité non plus ! Donc c’est à mon avis une mauvaise solution…
- autre piste, duckdns est classé par Google comme malveillant, donc tous les sous domaines qui en découlent aussi (plus ou moins)… Mais le port 80 n’a rien à voir là dedans. Et c’est juste le hasard que le truc semble résolu
Pour le reste, les liens proposés dans les anomalies indiquent les mesures à prendre pour corriger. Accessoirement on en a des exemples aussi sur le forum. Et puis bon, elles sont 6 mois
1 « J'aime »
Bonjour
Merci pour ton retour @Pulpy-Luke
Bon, de manière à supprimer les erreurs « unsupported » je suis reparti sur une fresh install (en m’appuyant sur ceci) = ça a résolu les erreurs « unsupported ».
Mais à nouveau je rencontre un problème de certificat quand je ne suis pas directement sur ma machine PI qui héberge HA supervised (donc smartphone, et PC); voici ce qu’il m’indique sur mon Smartphone :
Je vois le même token sur duckdns et HA :
Et les logs sont bons :
J’ai redémarré HA, mais aussi DuckDNS et cela ne change rien = voyez-vous ce qu’il faut que je fasse pour réparer cela ? 
Merci d’avance pour votre aide
Tu es certain que c’est la bonne url (celle que je viens de maquer dans l’image) qui est configuré dans le smartphone ? Et que ce n’est pas une autre url voire une adresse ip ?
oui c’est bien la bonne url (zut j’avais oublié de la masquer)
J’y accède habituellement via https://xxxxx.duckdns.org:8123
Et ton téléphone est bien réglé au niveau de la date/heure ?
Parce que là, HA indique que ton certificat est valable jusqu’en juin.
Tu peux faire le test avec un navigateur classique depuis le téléphone (pas via l’appli) ?
Date et heure sont correctes
Voilà ce que ça donne sur smartphone en dehors de l’appli qui tourne en boucle :
Moi (avec ton url) j’ai pas ça mais accès à HA mais à une freebox freebox
@Pulpy-Luke t’as oublié le port 8123
1 « J'aime »
Oui, le port 8123 ne donne rien… pas ouvert ?
EDIT:
Avec les yeux en face des trous c’est mieux
Donc le certificat que tu généres
n’est pas celui qui est utilisé
… Config yaml à vérifier
là vous m’avez perdu 
Je ne comprends ce que vient faire la console « mafreebox.freebox.fr » à cet adresse 
et moi qui vois autre chose en local.
Pour ce qui est du port 8123 il est ouvert (comme il l’a toujours été quand ça marchait 
) sur l’IP wifi du PI 192.168.1.40 (depuis quelques temps j’ai branché l’éthernet en cpl au pi qui a du coup aussi l’adresse eth 192.168.1.44, mais sans rien changer à mes configurations tout fonctionnait correctement)
Je vois bien les 192.168.1.40 et 192.168.1.44 en ip statiques
HTTP avec port 80 => console freebox
HTTPS avec 8123 => Ton ha avec un certificat KO
Vérifie ton fichier configuration.yaml,
La partie http n’utilise pas le certificat généré par let’s encrypt
Le 80 et 443 sont également redirigés sur 192.168.1.40
443 n’est pas ouvert…
Vérifie si tu n’a pas activé l’accès à distance de ta freebox par hasard. Et si c’est le cas, désactive le
J’ai désactivé l’accès à distance.
Envoi en cours : IMG_20230510_182624_edit_3819837000978.jpg…
J’ai supprimé 443, puis à nouveau redirigé 443 sur 192.168.1.40 (ip fixe wifi du pi), puis redémarré la Freebox, puis vidé les caches de l’app et du chrome smartphone, mais rien n’y fait : j’ai les mêmes messages via l’app et via l’URL 
Bon le 80 renvoi sur la freebox mais sans accès au login, c’est mieux.
Le 443 fermé et le 8123 ouvert.
Comme il n’y a qu’un seul port ne pas avoir le 443 c’est pas forcement génant. Le 80 ça m’ennuie un peu plus pour le prochain renouvellement
Reste à faut trouver les certificats (2 fois 2 fichiers) et adapter la config pour prendre les plus récents. Ce qui bloque c’est juste le certificat périmé
