Reprise du message précédent :
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é :
https://reho.st/medium/self/b805b1e [...] af3686.jpg
 
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 !
 

Hello, je me suis mis a hass.io +z2m y' a 2 semaines. Je me retrouve en décalé avec les mêmes questions que toi ^^(lovelace ui, card). Ou as tu paramétré le recorder ?
Merci

dans configuration.yaml, mais 15mn après avoir relancé HA la BDD n'était toujours pas amincie, donc je ne sais pas te dire si ça a fonctionné.

 
 
Si je dis pas betise, le recorder tronque les logs au redemarrage

pour tronquer la db sqlite de base, stop HA, delete le fichier et relancer, il n'y a pas d'autre solution (hormis passer par un client sqlite, il y a des discussions sur ce sujet sur le forum HA avec certaines commandes).

HA n'est pas prêt de devenir mon système principal

Il faut juste accepter que par défaut HA log tout, tout mais vraiment tout les update d'état de toute entité.
Suivant tes périphériques, cela conduit à faire grossir la db (et même ne serait-ce que les sensor weather sont mis à jour toutes les 10min ou du genre .... donc énormément de valeurs) - mais c'est bien ce qu'on lui demande en ne faisant aucune config.
 
Perso, j'ai passé 3 à 4 jours à voir comment utiliser le recorder/history/logger (attention ils ne font pas la même chose mais sont dépendant) proprement et surtout le maitre mot " qu'ai-je réellement besoin de sauver ".
Après je n'avait pas le choix, ayant pas mal de modules zwave, rien que les remontés d'info sur la consommation (+5 valeurs par périphs) qui est toutes les 60 sec +  changements - je passait à plus de 2 Go tout les 5 jours.

Et je rajouterais, pour un système principal, outre la configuration de history+logger+logbook+recorder -> passer sur influxdb pour le stockage long terme.

 
J'ai fait mon DaFunky, j'ai installé et configuré ma clé Zigbee2MQTT sous Domoticz, c'est vraiment easy tant qu'on suit le tutoriel
(et qu'on ne fait pas le boulet comme moi en oubliant d'alimenter la clé Zigbee durant le flachage.. )
 
J'ai 3-4 boutons Niu de Nodon qui traine chez moi( acheté à pas cher du genre 3€ le bouton)
J'aimerai pouvoir les intégrer dans mes scénario Domoticz
 
Ils dialoguent via BT LE, permettent de lancer une URL sous domoticz ou semblent connectable via Jeedom (je suppose que je devrais pouvoir faire pareil sous Domoticz..)
Pour ca, il me faut une cle BT sur mon serveur Windows / Domoticz
Vous avez des REX dans le choix de la clé BT (sous Domoticz) ou je prends le premier modèle venu (classe 1) ?

Pour vos databases. So vous utilisez la DB SQLite le service recorder.purge avec option repack.

Mais le purge ne supprimera que des records avec une date > limite donnée, et il me semble justement que pas tout est soumis au purge.

 
ça veut dire que tu te tapes toute la logique de tri des données à conserver dans HA, et ensuite tu te tapes toutes les stratégies de rétention de influx, qui sont en ligne de commande également, et je peux dire que c'est pas amusant. Et il y a de grandes chances de devoir sortir le tournevis à chaque ajout de capteur. Franchement j'ai mieux à faire de ma life. En face de ça domoticz possède une stratégie de rétention générale avec agrégation au fil du temps. Alors ok c'est frustrant, mais au bout de 4 ans de mesures d'une quarantaine de capteurs, j'ai une base qui fait 80mo sans avoir levé le petit doigt.
 
@Dephi : pourquoi tu dis "J'ai fait mon DaFunky"? J'ai mis la clé z2m sur Home Assistant

le service recorder.purge avec le soptions suivantes :

ça va faire un gros ménage. ça dégomme tout les états qui ont plus d'1 jour.
Et ça fait un repack (ré-écriture complète du fichier de base) qui peut permettre de réduire la taille du ficher de db (un peu comme un export/import, une réorg, une optimisation... enfin suivant les différents sgdb ça porte un nom différent quoi )

Montez vous une base InfluxDB alimentée (entre autre) par votre HA et vous serez peinard pour tout ce qui est historisation sans compter pour la restitution avec un joli dashboard Grafana

Au risque de me répéter : Influxdb = se coltiner toutes les stratégies de rétention de donnée, qui sont en ligne de commande, et je peux dire que c'est pas amusant. Et il y a de grandes chances de devoir sortir le tournevis à chaque ajout de capteur, je ne maîtrise pas assez la finesse du mécanisme, j'ai seulement passé une soirée à essayer de comprendre et maîtriser.

Honnetement avec Influx je n'ai rien réglé du tout - j'ai réglé côté HA ce dont j'avais besoin dans influx, ce n'est pas pareil et bien plus facile.
 
Maintenant oui, à l'ajout de capteur quel qu'il soit, faut rajouter ce dernier dans la conf HA pour influx. Mais d'un autre côté, tu ne mets que ce dont tu as besoin pour le long terme.
Après je comprend que tu puisses voir cela comme une contrainte - moi je vois soit comme avoir le contrôle et je préfère grandement avoir la maîtrise et la compréhension de ce qui est fait/stocké etc.
 
Et pour exemple, ma config influx (je ne sais pas si cela va te convaincre dafunky ^^):
 

 
Vraiment que ce dont j'ai besoin (sur un capteur avec 30 state, j'en stock que 1 ou 2 qui m'intéresse et que si le capteur m'intéresse pour des boards).

La stratégie de rétention peut être appliquée une fois pour toutes à la base...

Je préfère largement déléguer ce taff à une base Influx qui sera bien plus pérène qu'à un applicatif qui a déjà bien d'autres choses à faire ^^

Je fais ça depuis des années - mais avec Jeedom - et j'ai un très bel historique alors qu'avec les statistiques natives Jeedom j'aurai déjà tout perdu un bon paquet de fois sans compter la restituion qui est forcément très loin d'un Grafana

edit: ha my bad il faut ajouter les capteurs à la main

Euh ce point n'est pas une obligation. Moi j'ai pris le parti de faire un include pour n'avoir que ce que je souhaite ... mais on peut faire un exclude, un mix des deux, ou encore rien du tout !

Sur Jeedom j'ai pris le parti de tout - mais vraiment tout - envoyer vers Influx et au final c'est pas déconnant parce que quand il me vient l'idée d'un nouveau graph hé bien je suis très content d'avoir déjà tout d'historisé

dough29 je veux bien avoir le détail de tes stratégies, sachant qu'en principe il faut une stratégie de départ "fine" où on stocke toutes les valeurs et qu'on ne conserve que 24h (ou 48h ou 2h), ensuite une stratégie "moyenne" où on prend les séries de la première stratégie, on moyenne à l'heure (ou à la journée, ou à la semaine), et on déverse dans de nouvelles séries avec cette granularité, et pour finir une stratégie "grossière" où on prend les séries de la stratégie moyenne, on moyenne au mois (ou à la semaine, ou au trimestre), et on déverse dans des séries avec cette granularité.
 
C'est ce que fait domoticz sans même qu'on se pose la question, c'est ce que j'ai commencé à faire dans influxdb pour deux ou trois séries avant d'abandonner par manque de temps motivation, vu que dans le "tuto" que j'ai trouvé il faut tout déclarer manuellement, série par série, pour chaque niveau de granularité.
 
Si tu as un tuto pour faire plus simple et plus efficace je te serai éternellement reconnaissant

euh...ça vous sert à quoi d'historiser ces états ?
 
Autant je comprends historiser quelques états pour avoir un historique (genre quelques jours pour les températures...et encore), sinon je comprends pas l'utilité.

Dans Home Assistant, ui-lovelace, avez-vous une astuce pour afficher toutes les "entities" d'un composant ?
Au lieu de les lister une à une, un tips du style binary_sensor.mon_composant.*

 
Aucune utilité de garder plus de 12h pour 99% des métriques, la question est de savoir s'il est possible de trouver une stratégie qu'on pose une fois et qui mouline tout ce qui passe, ce qui permet d'être tranquille (approche domoticz), ou si on se repose la question à chaque ajout de matériel.  
 
Perso j'ai quelques scénarios un peu chiadés, et quand je tombe sur un comportement non souhaité j'ai besoin de savoir l'ordre précis de changement d'état de toutes les variables impliquées.
 
Typiquement mon alarme nocturne, j'ai un algo pour savoir si je l'enclenche ou non (par exemple quand je suis en vacances c'est l'alarme normale qui est active H24), et un autre algo pour savoir si je déclenche une alerte (en gros j'essaie de déterminer si c'est un habitant de la maison qui s'est déplacé ou si c'est un intrus).
 
Voilà voilà

@dafunky j'ai une première série brute sur une semaine, ensuite une autre au mois (downsample à 3 heures) pour finir sur une dernière en année (downsample à la journée).

Je ne sais pas si ce sont des choix des plus judicieux, mais ça fonctionne pas trop mal.

Pour moi l'intérêt c'est surtout de mettre en oeuvre ce type de service sans devoir attendre que ça tombe un jour au boulot, je me fais la main quoi

Après clairement je ne suis pas dessus tous les jours mais ça me permet quand même de comparer par exemple la consommation d'énergie en fonction de la saison et de la météo ^^

Pour le reste des capteurs c'est vrai que stocker par exemple l'état des ouvrants ça peut être discutable

C'est un parti à prendre entre avoir la donnée historisée des sa création ou ne l'avoir que quand on pense à l'exploiter.

edit : pour compléter > https://docs.influxdata.com/influxd [...] retention/

 
Utiliser monster-card ou auto-entities peut-être bien.

 
Je suis preneur de tes scénarios alarmes. Je suis en plein dedans

 
Merci.
 
Pour info, monster-card a été deprecated en faveur de auto-entities.
Je regarde auto-entities.

 
Je ne me souviens plus bien, et c'est assez spécifique à ma maison si je rentre dans le détail. Quelques règles :  
 
- A 1h du matin j'active l'alarme nocturne si l'alarme normale n'est pas active. Si un mouvement est détecté, je regarde depuis combien de temps le salon n'a pas été déclenché. Si c'est moins de 5 minutes, je ne déclenche pas d'alerte. ça permet de couvrir le cas où je me couche après 1h du matin.
 
- Quand j'active l'alarme normale, 5 mn après j'ouvre le volet de la chambre qui donne vers la rue, et 1 mn plus tard idem avec la 2nde chambre, pour simuler une présence. Sauf si l'alarme est activée après le coucher du soleil. Sauf s'il est entre 6h et 8h et que la T° extérieure est supérieure à 24° (situation de canicule), Sauf s'il est entre 8h et 10h et que la T° extérieure est supérieure à 26° (situation de canicule). Et je ferme tous les autres volets (qui donnent sur l'arrière du terrain).
 
- Quand le téléphone d'un habitant est détecté sur le wifi de la maison l'alarme est désactivée, sauf si l'alarme a été enclenchée depuis moins de 5mn (cas typique "j'ai oublié mon goûter sur la table, je reviens le chercher).  
 
Etc.

dites, j'ai des vannes thermostatiques domotisées dans chaque pièce et ma chaudière est controllée par un interrupteur zwave.
je me demande quelle est la meilleure solution pour activer/désactiver la chaudière afin de ne pas trop avoir de variations de température autour de la consigne tout en évitant d'avoir la chaudière allumée en permanence
actuellement je l'ai paramétré ainsi:

• si la chaudière est allumée, je coupe quand toutes les températures de consigne sont atteintes
• si la chaudière est éteinte, j'allume si la t° est inférieure à la consigne - 0,5° dans une des pièces ou si la somme des delta avec la consigne pour chaque pièce est supérieure à 1°
• je vérifie les températures réelles toutes les 5 minutes

des idées pour améliorer ça?

Dites, en zigbee et zwave, quelqu'un peut m'expliquer la notion de cluster et des exemples (ou un lien )
 
Merci

En zwave, je ne connais pas.  
 
Mais en zigbee, c'est en gros une table d'échange de données normalisée qui permet à un bidule connecté de discuter avec un autre.
 
Tu peux lire le préambule de ce document:
https://github.com/grostim/pimpMyBe [...] usters.pdf

 
Pour faire simple ton appareil zigbee est d'abord repere par son profil en general ZHA (home automation) ou ZLL (plus basique pour les lampes).
Apres il se divise en "endpoint", la c'est juste un chiffre en general "1"
Puis chaque endpoint contient les clusters, chaque appareil en a plusieurs en entrée et en sortie (0006 pr le on/off 0008 pour le level, ect ....)
A l'interieur des clusters tu trouves les attributs et les commandes qui dependent eux meme des clusters.
 
Ici tu as un exemple trouvé sur google avec deconz.
 

 
Les chiffre en noir sont les endpoints
Les chiffre en bleu sont les clusters entrée
Les chiffres en gris les clusters sortie
Entre parenthèses le nombre d'attribut connus de ce cluster

Du coup c'est un truc purement fonctionnel pour ce protocole?
 
Je m'attendais à une fonctionnalité pour "lier" directement par exemple un bouton à une ampoule, sans avoir besoin d'une passerelle. Mais après réflexion ça serait plutôt une faille si un gars se pointe avec un bouton et l'associe à ton équipement

Ce n'est pas une faille car pour que cela marche les lampes et les interrupteurs doivent deja être dans ton réseau, donc il y a deja eu négociation de clé et ect ...

Ces interrupteurs communiquent en groupe, donc tout les appareils dans le même groupe reçoivent les commandes (même sans passerelle).
Et le dernier jouet de xiaomi possèderait même la capacité de communiquer en broadcast sur l’intégralité du réseau juste après le reset, tant que l'on ne l'a pas associé a un groupe.

En pratique il suffit juste de mettre tout le monde dans le même groupe (et si besoin, "binder" les clusters de sortie de l’émetteur au groupe). C'est vraiment une commande de base.

Ca existe.
Il y a deux possibilités:
- Le binding, qui requiert une passerelle. tu te connectes d'abord à la passerelle puis tu configure un binding entre 2 périphériques.
- le touchlink qui permet de connecter directement 2 appareils. Il faut qu'il soit très proches (au contact, d'ou le nom).

Je me posais la question car actuellement j'ai la zigate avec d'un côté un switch xiaomi et de l'autre une ampoule osram. Mais avec "de la chance" l'interrupteur permettrait juste de faire un on/off, mais pour dimmer l'ampoule je dois forcément passer par domoticz

Il te faut juste un interrupteur qui supporte le direct bind.
Typiquement, le Hue dimmer, un switch ikea tradfri ou les nouveaux switch opple de xiaomi.

Bonjour,
J'utilise depuis peu une tête thermostatique Danfoss Living Connect LC-13 (Z-Wave, 014G0013) pour gèrer un radiateur (qui est sur chauffage centralisé collectif).
 
Je me demande comment fonctionne la "température de consigne" qu'on peut définir (soit directement sur la tête, soit dans notre logiciel de domotique préféré)
 
La tête n'accepte / propose que une température de consigne comprise entre 4 et 28° C.
Mais il me semble (après lecture ici notamment) que ce modèle n'a pas de sonde de température : donc à quoi correspond la température de consigne ?
Typiquement si je le mets à 28° j'ai bien l'impression que mon radiateur est à fond (comme si j'avais réglé l'ancienne tête thermostatique manuelle à 5, sur 5), mais si je le règle à 20° le radiateur est froid, comme si la vanne était fermée.
 
Je sais qu'il faut faire certains ajustements en fonction de la disposition/taille de la pièce et d'une sonde de température située dans la pièce et qu'au final quand je voudrais qu'il fasse 21° dans ma pièce je donnerais l'ordre d'être à la température de consigne fct(21) (où fct() est une fonction qui permet de calculer la température de consigne en fonction de la température de la chaudière ?, de la pièce ?, de dehors ?, etc. ?).
 
Mais, en l'était j'ai l'impression que :

• [4;20] = fermé
• [20;28[ = entre les deux
• 28 = ouvert

Ce qui me paraît anormale comme situation.
 
J'ai raté quelque chose ?

On progresse...
  WXKG02LM flashé avec succès.
  Appairé avec Zigbee2mqtt avec succès.
  Accepte la configuration de direct bind avec succès. (Un seul endpoint pour l'instant).
  J'ai pas réussi à configurer les I/O connectés au boutons... Donc pour l'instant, c'est inutilisable.
  Ca me gonfle sérieusement, car pour l'instant j'ai jamais réussi à faire en sorte que les devices transmettent un MODEL_ID ce qui est un prérequis pour créer une conf dans zigbee2mqtt.

Après des années sur HASS, je viens de switcher sur Hubitat, j'aime vraiment le fait que ce hub fonctionne sans cloud (possibilité de le link au cloud). Capacité d'intégrer avec l'externe via un clientmqtt et donc d'utiliser node-red.  
Je commence a explorer le truc mais à date je suis super agréablement surpris, il comble mon côté DIY et ajoute une part de stabilité lié au petit device commercial bien foutu.
 
https://hubitat.com/
Review du bousin : https://undecidedmf.com/episodes/20 [...] tat-review
 
Il y a 3 ans j'étais le premier à m'engager dans Home-assistant sur ce topic, je prédis que dans 3 ans hubitat aura pas mal de succès ici
 
Edit : La transition de Hass vers hubitat se fait super facilement, et on peut garder les 2 en //, l'app qui permet l'intégration mqtt a même des fonctions propres à Hass et utilise la convention homie (https://homieiot.github.io/)

C' est une des grosses régressions par rapport à domoticz pour moi