telemetry
Quoi de neuf

Fhem

  • Forum Electricité - Domotique
  • Auteur du sujet Auteur du sujet jcoenen
  • Date de début Date de début
  • #401
OPENHAB docker enfin activé.

Maintenant configuration de l'installation KNX, après 1/2 heure le thing gateway est connecté.

Définition d'un thing knx item ...

Mais que c'est compliqué
 
  • #402
Bon, voilà un graphe de mon SMA après une journée.

Il doit y avoir moyen de faire quelque chose pour maximiser l'auto-consommation en combinant mes données météo (% du nuages attendus) et la production SMA moyenne sur 5 minutes.... mais quels sont les gros consommateurs que je pourrais allumer et éteindre ??

upload_2020-10-26_18-4-18.png


Le jaune, c'est l'instantané 1 minute. Je dois encore essayer 1 seconde pour voir, mais ça charge les logs...
 
  • #403
Pas simple comme automatisation, mettre les gros consommateurs sur prise pilotable avec mesure de consomation, mais démarrer une machine à laver avec un cycle d’une heure et à partir d’une prise pilotée, plus vraiment possible avec les modèles actuels ???
 
Dernière édition:
  • #404
Ma machine à laver permet l'ajout d'un module EIB, la rendant compatible, et permettant ce genre de chose. Je dois encore voir le prix du module...
Mais en gros, ce n'est pas trop possible avec les reste, et je ne vois surtout pas comment faire (je ne vais pas éteindre le four quand il y a un nuage)... à part avec une PAC, pour laquelle on peut interdire ou autoriser le fonctionnement avec un contact sec prévu pour.
 
  • #405
Oui c'est le problème que j'ai directement rencontré. Maintenant, on pourrait optimiser sur l'ensoleillement et se dire que si soleil alors bonne production en moyenne, mais faire du suivit à la minute ca va pas être possible si les consommateurs fonctionnent en continu.

OK pour la machine à laver du futur, mais a ma connaissance les modules su ce genre de chose (içi on a la taque du cuisson et le four qui sont compatibles, mais les interface sont hors de prix et n'apportent pas grand chose).
 
  • #406
Ce qu'il faudrait, c'est pouvoir déconnecter un string en été, pour éviter de produire trop, le jour où il y aura une taxe d'injection.

Car en hiver, on a besoin de toute la puissance installée, mais pas en été.

Ou alors bricoler un truc avec un relais sur le côté DC de l'onduleur...
 
  • #408
ORES va installer des compteurs communicants avec possibilité pour le client de disposer des données du bus, via un "port client".

C'est une autre possibilité de récupérer les données, et de faire du pilotage.

Je vais investiguer...
 
  • #409
Effectivement, au niveau du compteur on devrait avoir la mesure (instantanée ?) de ce qui rentre/sort.

Et de developper un module FHEM ...
 
  • #411
pfffffff, c’est trop fastoche ....
 
  • #412
Ce qu'il faudrait, c'est pouvoir déconnecter un string en été, pour éviter de produire trop, le jour où il y aura une taxe d'injection.

Car en hiver, on a besoin de toute la puissance installée, mais pas en été.

Ou alors bricoler un truc avec un relais sur le côté DC de l'onduleur...
C'est exactement ce que je souhaite faire
je vais modifier mon installation actuelle (2x5Kva) en une seule (1x5kva) 2 strings de 10 panneaux 235wc au sud, et 2 strings de 9 panneaux 240wc à l'ouest et suivant l'ensoleillement, je laisse soit la totalité ou possibilité de couper un string au sud ou à l'ouest de façon à ne pas surcharger l'entrée DC de l'onduleur (sma5000tl21 dans mon cas)
 
  • #413
Et comment en pratique ? Avec des relais DC alors ?
 
  • #414
Et comment en pratique ? Avec des relais DC alors ?
L'idée serait de faire la lecture du courant dans un string coté sud et d'un string coté ouest, étant donné que j'ai 2 x 10 panneaux de 235wc (sud) et 2 x 9 panneaux de 240wc (ouest)
En connaissant le courant passant dans les différents strings, on peut en déduire approximativement la puissance et suivant le résultat, via relais (bobine 220vac) et contact de puissance (par ex.1000Vdc 20A) coupure d'un string au sud ou à l'ouest, ou les deux.
 
  • #415
C'est autorisé ce genre de relais sur la partie DC ?
 
  • #418
Je pense que ça vient de mon setup: mon Pi a ses données stockées sur mon Syno, sur un iSCSi target.

Comme tu es joueur, peux-tu essayer ceci sur ton Pi3 ?

dd if=/dev/zero of=test.file bs=64M count=1 oflag=dsync

Il a mis 7.69s chez moi (contre 1.25s en direct sur mon Syno).

Juste pour voir, ça vient peut-être de là...

Je viens d'essayer sur mon Pi4, via iSCSI sur le même Syno: 0.97s.

C'est donc bien le Pi qui limite à mort. Je suis déjà content de mon Pi4 alors qu'il n'y a que Raspbian dessus pour l'instant :)
 
  • #419
Effectivement, la vitesse du bus qui connecte la carte SD ainsi que la carte elle même sont les facteurs limitant, voici un article qui compare les vitesses d’accès USB et micro SD.

Avec le iSCSI les vitesses d’accès sont dépendantes de la bande passante du réseau (10/100/1000 MBps/sec), des performances du iSCSI target (CPU, mémoires …) ainsi que du support de données (SSD, HDD …) et de l’usage et la configuration du réseau (backbone, VLAN, priorités).

voici un autre article qui compare les deux, SD/iSCSI.

Mais en tout état de cause utiliser une carte SD n’est pas la meilleure des idées quand on cherche la performance.

Et bravo pour avoir implémenté le iSCSI en tout cas, ça doit aussi faciliter les sauvegardes.
 
  • #420
Je viens de finalement comprendre comment relier une instance de FHEM à une autre via un serveur MQTT.

Situation:
FHEM principal sur un RPi4, sur lequel tourne mosquito (mqtt)

FHEM secondaire sur RPi3 sur lequel j'ai un stick zWave.

Les deux sont maintenant relié par mosquito

Sur le FHEM principal je peux commander un switch zwave controlé par le FHEM secondaire et quand je commande le switch via zwave je vois l'état mis à jour sur le FHEM principal (donc tout baigne).

A gauche les messages envoyés par mosquito,
Au milieu FHEM principal (client mqtt)
A droite FHEM secondaire (avec zWave)
Je cliques sur le wallplug et le message on est publié par mqtt, reçu par FHEM Sec. qui allume le device correspondant (indicateurs on).

Capture d’écran 2021-11-07 à 16.10.42.png

Sur le FHEM sec, j'éteint le device ZWave_SWITCH_BINARY_3 en cliquant dessus le message est envoyé a mosquito, re9u par le FHEM primaire qui met le wallplug sur off.

Capture d’écran 2021-11-07 à 16.11.10.png

C'est pas mal une fois qu'on a compris la syntaxe des messages et la manière de les configurer.

Maintenant je peux relier toutes mes box (FHEM, openhab, homeassistant, jeedom ...) ensemble en passant par mosquito.

En cours de développement une interface mqtt pour le petit logiciel de VMC, sur les images, à gauche, on voit les messages d'état qui sont actuellement envoyés.

Et voici un changement de vitesse VMC piloté par une instance homeassistant qui est connectée à mosquito.

homeassistant envoie le message
VMC/cmd/vitesse 1

qui est lu par un client mqtt et qui commande la VMC sur vitesse 1 (niedrieg ou basse)
la VMC répond avec le topic mqtt VMC/data
qui contient les données dont la vitesse "2" qui correspond a la vitesse basse sur la VMC.



Capture d’écran 2021-11-07 à 16.19.57.png

Et maintenant en ajoutant un switch dans la config homeassistant

du genre

switch wallplug:
- platform: mqtt
name: "WallPlug"
qos: 1
unique_id: "ZWave_SWITCH_BINARY_3"
state_topic: "/ZWave_SWITCH_BINARY_3/state"
command_topic: "/ZWave_SWITCH_BINARY_3/state"
payload_on: "on"
payload_off: "off"


Capture d’écran 2021-11-07 à 16.40.42.png
Capture d’écran 2021-11-07 à 16.40.22.png

C'est formidable.
 
Dernière édition:

Sujet semblables

Réponses
5
Affichages
3K
@lex
Réponses
21
Affichages
3K
RobBZ
Réponses
2K
Affichages
208K
jcoenen
Réponses
3
Affichages
7K
pidgin

Nos articles

On a aimé dans le forum

Retour
Haut