Reprise du message précédent :

Pour cette raison précise, mon smartphone est sur Wall Plug depuis le tout premier jour (en réalité j'en suis à mon 2nd smartphone, le premier a fini par rendre l’âme, la couche tactile de l'écran déconnait, bien gênant les rares fois où j'avais besoin d'y toucher... un HTC de 2010, il a bien vécu)
Avant j'utilisais SMS Gateway, et Tasker à coté pour gérer les cycles de charge/décharge.
 
Depuis que je suis passé à JPI, c'est lui qui fait tout, c'est prévu pour. Il envoie directement les ordres HTTP à la box pour piloter le Wall Plug.

et c'est vraiment utile la charge/décharge de batterie vs branché h24 ?

Effectivement, il y a la solution prise connectée pour gérer le cycle de charge décharge mais bon, je trouvais ça un peu overkill... je suis passé à la clé 3G sur un vieux Pi2, ça fonctionne très bien
@Digaboy : les batteries ne supportent pas d'êtres branchées en permanence et ont tendance à gonfler

Je viens bien voir les sources !
Il n'y a aucun probleme a laisser un appareil en charge 24/24, ça réduit juste la durée de vie de la batterie (a cause du "trickle charging" ), mais vu qu'il est branché 24/24 même si la durée de vie est réduite de 50%, ça gêne pas non plus.
Elle se degradent plus vite aussi, mais elles evitent aussi comme ca les charges rapides, qui elles aussi degradent plus vite les batteries.

Même le probleme de température provoque par l'utilisation d'un appareil durant la charge, deviens minime.

Maintenant les batterie ne gonflent plus, elles explosent , il y a une dégradation chimique qui provoque un court circuit, mais il y a eu tellement de cas, que ça aussi c'est très etudiés (aucun constructeur de smartphone ne veut voir des cas de personnes ayant des telephones qui explosent, et il y en a plein qui le laisse en charge, trop de risques, les precautions sont prises)

Après faut voir le type de batterie, si le smartphone a 10 ans ...

Et cela concerne surtout les smartphones a cause de l'epaisseur reduite, il y a plus de personnes qui utilisent leur PC portables alimentés en 24/24, on voit rarement des cas d'explosions.

 
J'ai longtemps utilisé un MotoG (modèle 2014) avec JPI (tout comme Shaad   ) sauf que j'ai toujours eu la flemme d'installer une prise commandée
 
Et bien au bout d'un peu plus d'un an et demi, la batterie a gonflé  
Le téléphone est devenu inutilisable, je n'ai pas cherché à remplacer la batterie  
Ca vaut ce que ça vaut comme "source" mais si je devais le refaire je ne le laisserais pas en charge constante
 
(mais finalement je me suis aperçu que je n'avais pas vraiment des notifications SMS)  
 

Salut,  
 
J'ai un montage à faire avec le shelly 2.5, mais je ne suis pas trop sûr du câblage. Je veux :  
 
- L'alimenter en 220 ou en 24V, peu importe (facile avec le schéma ci-dessous)
- En sortie du relais 1, avoir idéalement la masse de mon alimentation 24V (moins évident), sinon je me contenterai du +
- Le relais 2 doit permettre de mettre un fil de mon moteur à la masse. C'est là que je sèche. Est-ce que je peux faire le montage "DC Wiring" et mettre le fil du moteur sur le O2?
 
 
EDIT : c'est bon c'est bien ça. Je contrôle un moteur DC dans les deux sens avec un shelly 2.5, c'est cool.
 

Pour moi tu as vraiment eu du bol alors de t'en rendre compte avant, je sais pas si c'est une batterie constructeur, mais quand elles éclatent, elle peuvent vraiment faire des dégâts.
Je viens de re vérifier, elle gonfle aussi, mais pas pour les même raison que les anciennes, quand elles gonflent, c'est une de leurs sécurités ( il faut mieux une batterie qui gonfle, qu'une batterie qui explose) mais c'est vraiment le cas extreme, aucun constructeur ne va te dire que leur batterie peuvent gonfler ou exploser, si c'est le cas c'est un defaut.

Il y a quelques années (pas si vieux), j'avais un Sony Xperia, et la batterie avait tellement gonflée qu'elle avait décollé la vitre arrière du smartphone.
 
Clairement il vaut mieux une batterie qui gonfle avant de prendre feu, que sans prévenir.
 
Autres points sur lesquels être attentifs avec les batterie, c'est la température. Il vaut mieux être au frais que derrière une vitre en plein soleil.
 
Sinon faut faire comme les adeptes de radiomodélisme, enfermer la batterie dans un bocal en verre ! Le feu ne peu plus se propager.
J'imagine qu'avec un petit trou dans le couvercle on doit arriver à faire passer le câble de charge (mais si le feu passe par là, c'est foutu)

Bon, c'est bon, j'arrive à contrôler mon rideau du salon avec google home.
ça m'aura pris la soirée, soit 3h30.  
 
- 1h pour Déballer le shelly 2.5, trouver le bon câblage (ce moteur DC ne se commande pas comme un volet), remarquer qu'il reboote dans certaines positions (à priori quand je lui mets sa coque en plastique), perdre du temps avec ça. Je ne l'ai même pas flashé en tasmota, je l'ai juste intégré à mon wifi avec l'app android, ensuite le plugin shelly de home assistant l'a découvert tout seul    
 
- 1h pour créer les automations commandables par MQTT : Ouvrir/Fermer/Stopper dans home assistant avec temporisations. (ouvrir = j'allume les deux relais puis je les coupe au bout de 13s, fermer = j'allume le relais 1 pendant 13s pendant que le relais 2 est fermé, etc.).
 
- 45mn pour créer un volet/rideau dans l'ui, créer les scripts d'ouverture/fermeture/stopper
 
- 45mn pour que google home le voie et le commande.
 
Grosso modo la moitié de ce temps à été consacrée à pester contre la syntaxe yaml
 

question con, pourquoi t'as mis un interrupteur pour les commandes ouvrir et fermer ? sur l'autre t'as un bouton exécuter.

La question n'est pas con, j'en sais strictement rien. Les trois scripts sont des copier / coller.

Mes scripts n'ont pas vocation à être montrés sur l'ui, pour moi c'est du backend. Sur l'image suivante c'est mieux présenté déjà :

Pareil, autre mystère avec les boutons de rideau : si j'appuie sur "haut" pour ouvrir le rideau, ce bouton se grise. Du coup si je fais "ouvrir" + "arrêter" je ne peux plus finir l'ouverture. Je ne peux que fermer.
La gestion des volets c'est une petite usine à gaz de paramétrage sur home assistant, en contrepartie on peut faire à peu près tout ce qu'on veut avec. Typiquement si tu as deux relais pour monter / ouvrir + un capteur pour savoir si le volet/porte de garage est ouverte, no problémo.

Pareil, j'ai pas tout compris mais apparemment on peut gérer le % d'ouverture pour à peu près n'importe quel système.

Là c'est configuré en mode basique, je verrai plus tard pour la personnalisation.

Si tu utilises l'ui lovelace auto générée a ce moment là tu dois spécifier par entité que tu veux la cacher:
https://www.home-assistant.io/docs/ [...] g-devices/

Merci. Suite à ton message, ça fait 30mn que je suis dessus sans succès.
1 - Activer le mode avancé sinon le menu "personnalisation" n'est pas accessible
2 - Aller dans configuration -> personnalisation
3 - Choisir l'entité souhaitée, ici j'ai choisi "all scripts (group)
4 - Choisir l'attribut "Hide from UI" et le cocher, sauver.
5 - Aller dans la section développement, onglet services, et lancer le service "homeassistant.reload_core_config"
 
J'ai vidé le cache, essayé sur un autre navigateur, refait la manip deux fois, c'est toujours visible.

reload locations & customizations dans server control ?
 
Je sais pas test car j'utilise une config lovelace custom.

Gégé DaFunky pour l'install !  
 
My2cents pour le débat HP/HC : je regarde attentivement ma conso pour voir si ça va être interessant. Je viens de recevoir la plus grosse facture de l'année je pense (Décembre/Janvier)
 
Aout/Sept : 200kWh de plus en HC
Oct/Nov : équivalent HP/HC
Déc/Jan : 550kWh de plus en HP (sur un total de 2500kWh, tout de même)
 
Sachant que je touche mes HC à -50% grâce à ma voiture électrique, je pense que ça va être rentable, on fera le bilan à la fin de l'année.  
 
Next step pour diminuer la conso électrique : je vais installer des extracteurs d'air depuis le salon (chauffé au poêle à granulés) vers qq pièces adjacentes, pilotés à grand renfort de domotique pour essayer d'assurer une température relativement homogène de partout.  
Je me demande si je pourrai considérer mon extracteur comme un thermostat dans Jeedom, puisque c'est lui qui va amener l'air chaud  

 
Le yaml est une invention du Diable... Le jour ou hass s'en débarasse, on aura un système proche de la perfection.

 
T'es pas en mode lovelace yaml (ou nom du genre) par hasard dans ton fichier configuration.yaml ?

J'envisage de faire poser une clim (un machin multisplit avec 1 split par chambre), j'aimerai bien pouvoir piloter ça par domotique (domoticz), il y a des marques/modèles/ plateformes à privilégier ?

Mitsubishi. 100% pilotable en local et plugin Domoticz existant.
 
edit : lien vers mon post si tu veux voir à quoi ça ressemble

J'ai une card custom pour mes volets qui règle ce problème :  

Daikin avec module wifi. Accès local et distant. Compatible home assistant et sans doute jeedom et domoticz

J'ai vu d'autres marques avec une gestion via le wifi, genre :
https://www.toshibaclim.com/Produit [...] i-B_-PKVSG
 
J'ai vu aussi que Atlantic/Fujitsu avait une espèce de box "IntesisHome " : https://www.domoticz.com/forum/viewtopic.php?t=28194
 
Est-ce qu'on peut supposer que tous ces systèmes peuvent du coup se piloter (même à la barbare avec des requêtes http directement) via une API ou alors il peut y avoir un truc relou cloud/https non snifable/... ?

Hello, ça reste assez rare, mais j'ai 2 petits problèmes : une prise connectée zwave neo coolcam qui parfois s'éteint puis se rallume, et une ampoule osram+ zigbee  qui s'allume.
Dans les logs domoticz je ne vois aucun événement sur ces devices.
 
Avez-vous déjà rencontré ça? Je me demande s'il ne pourrait pas y avoir un mini faux-contact qqpart

 
J'ai pas trop capté l'histoire du huzzah et du 5v/3.3V
 
Les ESP8266 du type NodeNCU à 3 euros, ils s'alimentent en 5V via prise micro USB (ou probablement aussi en envoyant le 5V sur la pin Vin). On ne peut pas directement faire clim 5V<->ESP8266 Vin ? (et pareil, en direct GND/RX/TX) ?

 
Merci, c'est exactement ce qu'il me faut.  
Peux-tu me mettre sur la bonne voie pour savoir où coller/adapter ce code? Pour le moment j'ai créé ça dans configuration.yaml :  
 
cover:
  - platform: template
    covers:
      salon_rideau:
        friendly_name: "Rideau Salon"
        #value_template: "{{ states('sensor.garage_door')|float > 0 }}"
        open_cover:
          service: script.open_rideau_cinema
     [...]etc etc[...]
 
Je dois le supprimer et le remplacer par ton bloc? Ou alors je dois remplacer ce que tu as mis : switch.close_store_chambre avec mon script.open_rideau_cinema? Et l'état ouvert/fermé de ton volet est géré où du coup?

nope ça c'est de la config pour lovelace
je te fais un gif
https://reho.st/gif/84ee41df7d1aeef [...] e5bcaf.gif
 
après faut remplacer les switch.xxxx qu'il a par les tiens.

 
Les esp8266 ne sont pas faits pour prendre des tensions de 5v sur leurs inputs. Donc si t'as une interface série avec un truc qui balance du 5v => pas bon ou alors pas longtemps.
 
Donc sois tu prends une carte qui prend du 5v (comme la huzzah), soit tu fais un pont diviseur de tension toi même pour ton esp8266 afin de baisser la tension avant que ça arrive sur l'entrée.
 
Que quelqu'un me corrige si c'est pas exactement ça.
 
Je me suis pas fait chier pour 10€ j'ai pris la huzzah.
 
edit : un blog où le mec détaille bien la partie hard  
https://chrdavis.github.io/hacking- [...] mp-Part-1/
https://chrdavis.github.io/hacking- [...] mp-Part-2/

 
Pourquoi donc ?

 
Merci pour le gif. Je suis quand même paumé : si toi tu n'as pas lovelace, tu as quoi?

 
Ben justement le mec du lien prend un clone de wemos D1 mini et semble lui envoyer le 5V direct
l'ESP8266 de mon lien aliexpress c'est typiquement le truc qui s'alimente en 5V via USB. La régulation est donc prévue sur la carte (et on a accès à une pin 3.3V si on veut).

sisi j'ai lovelace, on a tous lovelace sous hass.
Le truc c'est que soit tu as lovelace "auto-généré" en gros il ajoute toutes tes entités de manière +- groupée.
Soit tu te fais une config custom avec des onglets comme tu le souhaites et les entités que tu veux dans l'ordre que tu veux.
 
Je suis sous hass depuis perpet et sous lovelace depuis le début que ça existe ET au début il n'existait pas de version générée automatiquement donc je ne sais pas comment cela fonctionne pour passer de l'un à l'autre.

Attention il y a l'alim et les IO comme tx rx.

 
Oui c'est bien résumé. Avec les cartes de prototypage connues la tension max recommandée en entrée est celle prévue par le esp8266 , soit 3.3v. Un pont diviseur de tension est une pratique habituelle, il suffit d'avoir une petite pochette de résistances 4.7kOhm et 10kOhm et t'es paré pour longtemps.
 
A noter que l'ESP8266 est réputé tolérant au 5V, du coup une astuce est de mettre une résistance de 10kOhm en série sur l'entrée 5V, le courant sera faible et ça fonctionnera dans la plupart des montages. Sinon la huzzah évite de se poser ces question
 
@Départ : les cartes de prototypage ESP8266 s'alimentent en 5V, mais les GPIO viennent directement  de l'esp, qui fonctionne en 3.3V en entrée et sortie, et 0-1v pour l'entrée analogique.

Parce que le yaml est extrèment "exigeant" sur la syntaxe, c'est à mon sens le principal frein à l'utilisation des scripts et automation de Home Assistant. Si ils avaient utilisé un système de script à la Jeedom, je pense que nous serions beaucoup moins nombreux à utiliser nodered en parrallele de home assistant.

 
Ce n'est pas ça dont tu parles  ? :
https://www.home-assistant.io/lovelace/yaml-mode/
 
Je passe assez souvent de l'un à l'autre suivant mes besoins.
Il ne faut surtout pas oublier de copier la conf fournie par l'IHM dans le fichier ui-lovelace.yaml quand on passe on mode yaml et faire l'inverse quand on revient en mode graphique.
 
Hass c'est définitivement pas pour madame Michu.... vivement la 1.1 ou 1.2 !    

 
Tout +1    
 
Même j'adore NodeRed c'est vrai que ça fait une surcouche et que l'intégration est encore un peu perfectible

nope je parle d'être en mode storage (par défaut quoi) mais sans fichier config lovelace dans ton répertoire .storage
Je viens de tester en retirant le fichier dans ma config.
Je me retrouve avec toutes mes entités sur l'onglet par défaut de hass puis si j'ouvre le menu configure UI j'ai ceci:

Désolé, je t'ai collé le code sans explications.
Mes volets sont gérés par un broadlink qui envoie un code radio pour l'ouverture, la fermeture et le stop. J'ai donc créé des scripts pour chaque fonction "switch.close_store_chambre", bien évidement il faut que tu remplaces par tes switchs à toi.
Je gère l'état via un capteur d'ouverture Xiaomi qui dans le script est : binary_sensor.cover_chambre.
 
Ce code se colle dans une manual card de ton interface lovelace comme dans le gif de big poulet.
 
Si tu bloques, dis moi ou tu en es.

Sinon, la BDD c'est une bombe à retardement sous home assistant si on ne met pas les mains dans le cambouis. ça fait 10j que c'est en place, j'ai mis deux sondes de T° et deux boutons non utilisés, ainsi que le plugin unify, et la bdd fait 400mo
J'ai paramétré le recorder du coup, je ne garde pratiquement rien.

Petite question, j'ai essayé d’intégrer des prises Ikea à Zigbee2MQTT et pas moyen, je suis en mode inclusion mais rien ne remonte.
Je dois mal resetter la prise ou un truc comme ça mais je vois pas comment faire.
La doc Z2M ne m'aide pas trop pour le coup

Perso avec la zigate j'ai galéré pendant 1h pour intégrer mes 3 répéteurs usb ikea (le premier niquel du premier coup mais les autres...). Je me suis rapproché de la zigate pour que ça fonctionne. Si c'est similaire rapproches toi de ta clé zigbee

Il se passe un truc super super chelou avec mon domoticz (latest beta, cherchez pas, j'ai essayé de revenir à la dernière stable, ça ne démarre pas):
j'ai changé de fournisseur d'électricité et j'en ai profité pour dégager les HC/HP pour repasser en abonnement BASE.
J'ai un script (sur device change) qui fait un appel http à une page de mon serveur web local pour récupérer dans ma base de données à moi les infos.
Ca tourne depuis des années sans souci.
 
Depuis la bascule, domoticz laggue sur la remontée d'infos, en gros quand je récupère les données dans ma bdd je vois qu'elles arrivent avec du retard, style à 8h00 je vais récupérer la valeur de 7h50, puis au fil de la journée ça se décale de plus en plus. Là 16h après le dernier reboot complet du raspberry, j'ai 1h45 de retard ! Si je redémarre domoticz tout revient dans l'ordre... un moment.
Bizarre non ?
 
En terme de processus ça a l'air un peu chargé :

 
C'est comme si la bascule HC/HP avait augmenté la fréquence des remontées teleinfo (peu probable) et que derrière ça n'arrivait plus à suivre.
 
Ce qui est encore plus étrange c'est que le log temps réel de domoticz me donne des trucs genre :
2020-01-30 11:41:55.642 Status: LUA: https://ip_madomotique/domotique/lo [...] 351&hchc=0
2020-01-30 11:41:55.642 Status: EventSystem: Fetching URL https://ip_madomotique/domotique/lo [...] 351&hchc=0 after 0.2 seconds...  
Et qu'en BDD je n'ai rien qui correspond... l'évènement enregistré à cette heure et une valeur de téléinfo bien plus ancienne !!! weird !