Pour passer de la V4 à la V4.1.20, j’ai refait une installation neuve sur Debian 10 et ai transféré ma dernière sauvegarde fonctionnelle. Tout c’est bien passé. Mais il y a un changement que je ne comprends pas et qui semble me bloquer pour un accès via smartphone :
Avant je me connectais en local via 192.168.0.183 :1980 . Idem via mon smartphone grâce à l’installation d’un VPN.
Depuis la 4.1.20, l’accès sur mon pc reste 192.168.0.183 avec obligation de supprimer le port.
En local sur mon pc, je retrouve l’accès sans problème mais en utilisant l’appli jeedom via le smartphone, impossible de se connecter (j’ai bien évidemment essayé de supprimer le port dans les accès interne et externe dans la config).
Attention : cette configuration n’est là que pour informer Jeedom de sa configuration réseau et n’a aucun impact sur les ports ou l’IP réellement utilisés pour joindre Jeedom
J’ai vu @olive en effet. J’ai fixé l’IP du RSPI avec mon routeur. Ensuite j’ai gardé tous les ports fermés puisque les infos passent via OPENVPN. En fait je n’ai rien changé par rapport à l’ancienne V4 avec l’ancien RPI3B+. J’ai juste indiqué à mon routeur que l’IP 192.168.0.183 était réservée pour le nouveau num MAC du nouveau PI.
Mais, pas d’accès externe. J’ai dû louper un truc ?
Avec cette commande, j’ai modifié le port en conséquence et l’accès est redevenu 192.168.0.183:1980
Pour la confif sur android, il faut au préalable remettre le port sur la config Jeedom Réglage/système/configuration/réseau car même en modifiant les liens internes et externes sur l’appli android, celle-ci va chercher la config sur le pi et annule la modif.
Donc ce point est résolu. Merci @olive@Fabrice
Maintenant il faut que je comprenne pourquoi je ne retrouve pas mon DESIGN sur l’appli. J’ai juste une page blanche.
Question au sujet du port :
Pourquoi en local, voulez-vous utiliser Jeedom sur un port :1980 ? En local, vous pouvez rester sur le port par défaut (80, donc rien à spécifier sur vos appareils locaux).
Sans rapport :
Je regarde votre photo en haut, et je vois un hub USB qui n’est pas alimenté sur lequel vous avez un disque et un contrôleur.
Pourquoi ce hub pour un Raspberry Pi3B+ ? (tel qu’il est, c’est juste une source de consommation supplémentaire et donc nuisible).
Citation *Question au sujet du port :
Pourquoi en local, voulez-vous utiliser Jeedom sur un port :1980 ? En local, vous pouvez rester sur le port par défaut (80, donc rien à spécifier sur vos appareils locaux).
Cela date d’avant , lorsque je laissais un port ouvert pour accéder de l’extérieur. Maintenant que je passe par un VPN, en effet je peux remettre le port en 80.
> Citation Sans rapport : Je regarde votre photo en haut, et je vois un hub USB qui n’est pas alimenté sur lequel vous avez un disque et un contrôleur. Pourquoi ce hub pour un Raspberry Pi3B+ ? (tel qu’il est, c’est juste une source de consommation supplémentaire et donc nuisible).
J’apprécie votre perspicacité
Il y a quelques semaine, j’ai voulu profiter du passage de la V4 à la V 4.1.20 (nécessitant une installation Debian 10 toute neuve), pour abandonner la SD au profit d’un SSD.
J’ai suivi votre tuto sur ce forum : tuto pi + SSD
J’ai tout essayé pour que le PI 3B+ boot sur le SSD (Msata) mais rien n’y a fait. J’ai même acheté un autre ensemble complet Pi3B+ - Msata - alim 3A, changé de capacité de SSD (128Go à 64Go dans une autre marque), j’ai même shunté la ligne 5v sur la carte : Nada il n’a jamais voulu booter sauf si je laissais une SD.
Même le test de voltage ne montre aucun défaut. La mesure indique 5.10 à 5.12 V L’écran de couleur ne s’affichait même pas.
Comme je suis du genre tenace, j’ai acheté un HUB alimenté pour l’intercaler entre PI et Msata. Ö Miracle, il boot sans SD, et j’ai renouvelé sur le premier ensemble PI + Msata 128Go : idem il boot sans aucun pb avec le HUB alimenté.
Hier j’ai installé l’ensemble sur mon tableau comme sur la photo et ça marche impeccable. Mais comme vous avez pu le détecter, j’ai oublié de brancher l’alimentation du HUB : histoire de fou, le PI boot sans problème, alors que sans le HUB : il ne boot pas. Je soupçonne que le HUB contienne un condensateur qui absorbe l’appel de courant sur le +5V et permet à l’électronique du SSD de s’initialiser.
Voilà l’histoire.
