Fhem

jcoenen

• 11 Avril 2020

• #321

Une solution parmis d'autres:

Problème

IF première détection
THEN allumer lampe pendant 60 secondes
ELSE

IF (la deuxième détection arrive moins de 30 secondes après la première) allumer la lampe en continu
ELSE allumer lampe pendant 60 secondes
​

DEVICES
le détecteur de présence est le device detecteur
la lampe du garage est le device KNX_0101015


Une variable watched (dummy) eest définie celle-ci determine si on est dans le cas première détection ou deuxième detection, cela se fait en mettant la valeur ON pendant 30 seconde après première détection

Ensuite dans le notify du détecteur (détection) on teste watched pour voir dans que état on est et ce qu'on doit faire avec la lampe.

Enfin un notifier est placé sur l'extinction de la lampe pour forcer le retour a première détection.

En language FHEM

define watched dummy
attr watched room garage
attr watched setList on off
attr watched useSetExtensions 1

define detection notify detecteur { if(Value("watched") eq "off") {fhem("set KNX_0101015 on-for-timer 60") ;; fhem("set watched on-for-timer 30")} else {fhem("set KNX_0101015 on") ;; fhem("set watched on")} }
attr detection room garage

define resetwatched notify KNX_0101015ff set watched off
attr resetwatched room garage


j'ai utilisé une variable detecteur pour simuler le détecteur de présence

define detecteur dummy
attr detecteur room garage
attr detecteur setList on off

A mon avis il doit y avoir d'autre moyen de réaliser la même chose par exemple avec DOIF, mais bon l'essentiel c'est que ça fonctionne.

 

jcoenen

• 11 Avril 2020

• #322

J'ai le même problème dans mon garage (KNX)

Le détecteur peut détecter toute les minutes
Lampe actuateur avec timer de 2 minutes (escalier) qui peut être réarmé

Détecteur sur l'entrée de l'actuateur, a chaque détection le timer est réarmé.

 

@lex

• 11 Avril 2020

• #323

Merci !

Un truc que je vois: si tu restes dans le garage, la lampe ne s'éteindra pas lorsque tu pars, après par exemple 15 minutes.

Il doit y avoir moyen qu'elle s'éteigne x minutes après la dernière détection.

 

jcoenen

• 11 Avril 2020

• #324

Ok, je pensais que dans le cas de forçage à ON continu l’extinction soit manuelle (car comment peut on déterminer qu’on a fini ?)

Tu pourrais remplacer le forçage à ON par un set lampe on-for-timer 900
Dans ce cas tant que la lampe ne s’éteint pas chaque détection remet 15 minutes sur l’allumage

 

@lex

• 11 Avril 2020

• #325

Ça fonctionne !

Merci ! (et peut-être merci au confinement )

 

jcoenen

• 11 Avril 2020

• #326

Hahahaha effectivement, j’ai beaucoup de temps a ma disposition et suis doublement confiné à cause d’une fracture de la hanche

Et content que ce soit ce que tu cherchais !

 

eljub

• 11 Avril 2020

• #327

jcoenen a dit:

suis doublement confiné à cause d’une fracture de la hanche

Cliquez pour agrandir...

ouch !

soignes toi bien !

 

jcoenen

• 11 Avril 2020

• #328

Merci, ça va faire un mois (juste avant le confinement et donc pas de visite à l’hosto, mais bon avec un smartphone c’était parfait)

Maintenant j’ai quitté la chaise roulante pour les béquilles donc ça va de mieux en mieux en tout cas merci de votre support

 

@lex

• 12 Octobre 2020

• #329

Bonjour !

J'ai pas mal de messages identiques dans mon logfile:

autocreate: define FileLog_KNX_0000000 FileLog ./log/KNX_0000000-%Y.log KNX_0000000

D'où vient-ce ?

 

jcoenen

• 12 Octobre 2020

• #330

fhem crée (ou essaye de créer) un fichier log pour le device sur le groupe 0/0/0 lorsqu'il voit un message avec l'adresse de groupe 0/0/0

Dans la configuration cela est géré par

define autocreate autocreate
attr autocreate filelog ./log/%NAME-%Y.log

l'autocreate (crée un nouveau devise sur un groupe d'adresse non encore définit dans FHEM) n'est plus nécessaire une fois que tout les devices ont été détectés.

sur la page http://{adresse IP}:8083/fhem?detail=autocreate

mets l'attribut diable sur 1 pour désactiver autocreate.

Ou alors si tu veux garder autocreate actif, enlève l'attribut filelog (pas de création de fichier de log lor de la détection d'un nouveau device).

Pour la petite histoire mes voisins ont installés des appareils sans fils que mon RFXcom détecte et cela m'a créé une volée de fichier log qui a un moment donné m'ont bloqué le Raspberry (trop de fichier ouvert).
Je ne sais pas ce qu'ils ont bricolé mais j'avais quelques centaines d'adresses.

Donc prudence avec autocrate.

 

jcoenen

• 12 Octobre 2020

• #331

La preuve ... j'installe un nouveau serveur et surprise:



Ce sont des modules RF de détection de fumée (RM174RF), d'ouverture de fenêtre DM10A, détecteur de mouvement MS10A.

Pour éviter de genre de pollution utiliser l'attribut ignoretype

attr autocreate ignoreTypes (TRX_DS.*|TRX_RM.*|TRX_MS.*)


et pour zigouiller ces indésirables:

delete TRX_RM174RF.*

Fastoche, l'autre fois j'avais fait tout à la main ca m'avait pris la journée.

 

@lex

• 12 Octobre 2020

• #332

Nickel, merci !

Autre problème, j'ai fait un graphe SVG pour afficher les 4 températures de la VMC. Le graphe ralentit mon Pi, au point que j'ai dû éditer le fhem.cfg à la main pour supprimer ce graphe (à chaque affichage, j'avais fhem qui prenait 100% du CPU pendant plusieurs minutes !!!)

Je me demande à quoi c'est dû.

Au refresh de l'objet VMC toutes les 60 secondes ? C'est un Pi3, normalement, c'est quand même rapide.

Et mes objets sont bien tous définis en KNX...

 

jcoenen

• 12 Octobre 2020

• #333

les graphiques peuvent prendre beaucoup de temps en fonction de l'intervalle de temps demandé, de l'échantillonnage, du nombre de fichiers accédés.
Je suppose que toutes les données sont dans un seul fichier.

J'échantillonne toute les 5 minutes (300 secondes dans la définition), ce qui fait 5 fois moins de données que de ton côté, donc 1 jour chez toi c'est 5 chez moi aux niveau échantillons.

Ici une journée 4 températures prend 4 secondes sur le pi 3 par contre sur le Pi 4 ça prend moins d'une seconde (un mois complet = 30 secondes, avec le 3 je n'essaye même pas).

le 3 est sur une carte SD, le 4 est sur un SSD USB 3 et au niveau vitesse et fiabilité c'est imbattable.

Pour une journée, quelques minutes c'est vraiment exagéré, il doit y avoir un stuud quelque part

Pour voir ou ça coince, essayes de faire une température à la fois (quel est l'intervalle de temps ?) le défaut c'est un jour mais l'attribut fixedrange permet de le changer (day, week, month, year ...)

pour info voici mon graphique (en vert les périodes de bypass)


pi 4

Et sur le pi 3 une semaine complète (25 secondes)

 

Dernière édition: 12 Octobre 2020

@lex

• 14 Octobre 2020

• #334

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à...

 

eljub

• 14 Octobre 2020

• #335

Platform = Raspberry Pi 3 Model B Rev 1.2

 

jcoenen

• 14 Octobre 2020

• #336

voici voilà j’aime bien ce genre de test

 

jcoenen

• 14 Octobre 2020

• #337

en tout cas sdcard 7 secondes, SSD usb 3 0,72 sec

C’est clair, 10x plus rapide ...

ISCSI tu m’en diras tant, network latencies c’est tout à fait normal ...

 

@lex

• 15 Octobre 2020

• #338

Merci !

Mon Syno n'est pas tout récent, et bien chargé, surtout les disques, donc ça explique aussi en partie...

Maintenant je sais pourquoi les graphes sont lents... faudra que je passe au SSD USB...

 

jcoenen

• 15 Octobre 2020

• #339

Je viens d'essayer sur mon pi 3 (celui en production)

pi@raspb2 ~ $ dd if=/dev/zero of=test.file bs=64M count=1 oflag=dsync

1+0 records in

1+0 records out

67108864 bytes (67 MB) copied, 11.64 s, 5.8 MB/s


et sur le pi 4 avec le SSD

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

1+0 enregistrements lus

1+0 enregistrements écrits

67108864 octets (67 MB, 64 MiB) copiés, 0,648161 s, 104 MB/s

Y'a pas photo, pour info j'utilise un SSD PNY de 480 GB (60€), il y en a de 240 GB à 40 € tout les deux USB 3.1

Avantages:
- rapport capacité prix comparé aux cartes SD;
- résilience (les SSD ont d'autres type de mémoires interne plus robustes et avec une meilleure gestion du wear leveling), donc le SSD vivra plus longtemps.
- Vitesse d'entrée/sortie (voir le test, 104 MB/s vs 5.8 MB/s )

Le raspberry peut maintenant booter à partir d'un disque USB et donc ce n'est plus un problème.

Le seul "inconvénient" c'est une petite boite en plus et on consomme un port USB, mais au vu des avantages, on peut accepter de vivre avec.

 

@lex

• 17 Octobre 2020

• #340

Je pensais que c'étaient mes caméras sur le Syno qui pompaient le disque, mais la performance augmente à peine quand je les désactive.

Tu pourrais essayer le Pi3 avec le SSD, si c'est possible ? Juste pour voir....