Heure de la dernière communication.
-
- Timide
- Messages : 125
- Inscription : 01 janv. 2017, 23:41
Heure de la dernière communication.
Bonjour,
Je cherche à récupérer dans un scenario l'heure de la dernière communication avec un équipement.
J'ai réussi à avoir la date et l'heure complet avec un collectdate() , mais je ne trouve pas comment ne garder que l'heure.
Est-ce possible ?
Merci
Je cherche à récupérer dans un scenario l'heure de la dernière communication avec un équipement.
J'ai réussi à avoir la date et l'heure complet avec un collectdate() , mais je ne trouve pas comment ne garder que l'heure.
Est-ce possible ?
Merci
Re: Re : Heure de la dernière communication.
c'est assez simple.
collecdate peux etre utilisé avec une fonction sortie date php (revoir doc scenario)
en bloc
format timestramp U collectDate(#[Cuisine][Porte Cuisine][Etat]#, U)
en code (vu que tu en fait)
$tmp = scenarioExpression::collectDate($_cmd, $_format = 'U');
collecdate peux etre utilisé avec une fonction sortie date php (revoir doc scenario)
en bloc
format timestramp U collectDate(#[Cuisine][Porte Cuisine][Etat]#, U)
en code (vu que tu en fait)
$tmp = scenarioExpression::collectDate($_cmd, $_format = 'U');
-
- Timide
- Messages : 125
- Inscription : 01 janv. 2017, 23:41
Re: Heure de la dernière communication.
Et en abusant un peu.
J'aimerai faire soustraction de 2 de ces heures ? (pour mesurer l'écart entre 2 communication)
J'aimerai faire soustraction de 2 de ces heures ? (pour mesurer l'écart entre 2 communication)
-
- Actif
- Messages : 1332
- Inscription : 27 juin 2015, 21:53
- Localisation : Dijon
Re: Heure de la dernière communication.
Strtotime(collectdate(#tonequipement#)-timestramp
Résultat en seconde
Envoyé avec TapataCash !
Résultat en seconde
Envoyé avec TapataCash !
Mon Matos
Mon Blog où vous trouverez des astuces et tutos Tasker/Jeedom
Mon alarme sous Jeedom
Tuto pour la Gestion de la présence
Mon Blog où vous trouverez des astuces et tutos Tasker/Jeedom
Mon alarme sous Jeedom
Tuto pour la Gestion de la présence
Re: Re : Heure de la dernière communication.
pas mal
#timestamp# - collectDate(#[Cuisine][Porte_Cuisine][Etat]#, U) > 3 (> < à x seconde)
timestamp (sans r est dans la doc scénario)
j'utilise ça pour plein de trucs
contrôles sondes, portes, nuts,chauffages,...
c'est pas de moi
là pour rosty tuto je refaisait un vieux truc / différencier une action jeedom vs interrupteur/telecom (zwave/rfx...)
c'est dans ma signature pour des VR
je voulais le refaire pour mon telerupteur qu'un pir allume.
avec les nouvelles possibilités de jeedom
un truc fastidieux là d'une facilité
1 scenario 1 if 1 faire
1 info et 1 action
en plus du on/off info zwave
et devine le seul if
#timestamp# - collectDate(#[Maison][Entrée][Actionner par Jeedom]#, U) > 3
#timestamp# - collectDate(#[Cuisine][Porte_Cuisine][Etat]#, U) > 3 (> < à x seconde)
timestamp (sans r est dans la doc scénario)
j'utilise ça pour plein de trucs
contrôles sondes, portes, nuts,chauffages,...
c'est pas de moi
là pour rosty tuto je refaisait un vieux truc / différencier une action jeedom vs interrupteur/telecom (zwave/rfx...)
c'est dans ma signature pour des VR
je voulais le refaire pour mon telerupteur qu'un pir allume.
avec les nouvelles possibilités de jeedom
un truc fastidieux là d'une facilité
1 scenario 1 if 1 faire
1 info et 1 action
en plus du on/off info zwave
et devine le seul if
#timestamp# - collectDate(#[Maison][Entrée][Actionner par Jeedom]#, U) > 3
-
- Timide
- Messages : 125
- Inscription : 01 janv. 2017, 23:41
Re: Heure de la dernière communication.
Vous êtes trop fort !!!
Des que j'ai un peu de temps, je me plonge dedans.
Si je resume
timestamp - collectdate
=> nombre de seconde écoulé depuis la dernière communication
Collectdate(eq1,U)-collectdate(eq2,U)
=> délai entre les 2 dernières communication de mes équipements
Merci encore
Des que j'ai un peu de temps, je me plonge dedans.
Si je resume
timestamp - collectdate
=> nombre de seconde écoulé depuis la dernière communication
Collectdate(eq1,U)-collectdate(eq2,U)
=> délai entre les 2 dernières communication de mes équipements
Merci encore
Re: Heure de la dernière communication.
J'ai aussi une petite question dans le même genre ...
Je peux récupérer les infos de ma caméra avec l'heure de dernière vue de qqn ... mais le format est : 2017-04-03 18:37:17
comment le transformer en : 1837 pour que je puisse la soustraire de #time# et savoir en hhmm depuis combien de temps la personne à été vue par la caméra ?
merci d'avance ...
Je peux récupérer les infos de ma caméra avec l'heure de dernière vue de qqn ... mais le format est : 2017-04-03 18:37:17
comment le transformer en : 1837 pour que je puisse la soustraire de #time# et savoir en hhmm depuis combien de temps la personne à été vue par la caméra ?
merci d'avance ...
Re: Heure de la dernière communication.
Je suppose que tu peux utiliser la fonction date:
dans ton cas: date(Hi,$tontimestamp)
Il faut donc que tu convertisse ta date en timestamp avec strtotime
si ta date est $tadate ça donnerait: date(Hi,strtotime($tadate))
si tu ne passes pas par une variable: date(Hi,strtotime(2017-04-03 18:37:17))
on peut certainement faire aussi avec date_format
dans ton cas: date(Hi,$tontimestamp)
Il faut donc que tu convertisse ta date en timestamp avec strtotime
si ta date est $tadate ça donnerait: date(Hi,strtotime($tadate))
si tu ne passes pas par une variable: date(Hi,strtotime(2017-04-03 18:37:17))
on peut certainement faire aussi avec date_format
Jeedom sur vm esxi stretch
Principaux plugins: eibd, homebridge, maxcube, icalendar
Principaux plugins: eibd, homebridge, maxcube, icalendar
Re: Heure de la dernière communication.
Merci pour ta réponse ... mais désolé, j'ai pas tout compris ...caplam a écrit :Je suppose que tu peux utiliser la fonction date:
dans ton cas: date(Hi,$tontimestamp)
Il faut donc que tu convertisse ta date en timestamp avec strtotime
si ta date est $tadate ça donnerait: date(Hi,strtotime($tadate))
si tu ne passes pas par une variable: 2017-04-03 18:37:17
on peut certainement faire aussi avec date_format
Je dois passer par un bloc code, ou je peux l'utiliser dans une action ?
Pour être concret, l'infos est reprise dans : #[Salon][Welcome Salon][Derniere fois Manu]# = 2017-04-03 18:37:17
Je l'ai mise dans une vaiable dans un bloc :: variable - Test - #[Salon][Welcome Salon][Derniere fois Manu]# --> Test = 2017-04-03 18:37:17 (vérifié)
et si dans l'étape suivant je mets : :: variable - Temp - date(Hi,strtotime(#[Salon][Welcome Salon][Derniere fois Manu]#)) --> Temp = 161
si je mets :: variable - Temp - date(Hi,strtotime(Test)) --> Temp = 161
et si je mets :: variable - Temp - date(Hi,strtotime(2017-04-03 18:37:17)) --> Temp = 1837
Je pense que c'est le format de la variable qui n'est pas correcte,mais je ne sais pas pourquoi ... ?
Et comme in fine je voudrais pouvoir mettre dans une condition (#time# - (variable(Temp))
Merci de ton aide ...
Re: Heure de la dernière communication.
J'ai même essayé en code, mais rien n'y fait ...
les variables Manu, chrystel et Sophie contiennent bien l'horodatage complet : 2017-04-05 17:34:39
les variables XXheure sont par contre fausses ... : 171 ...
??
Code : Tout sélectionner
// Récupération des valeurs heures brutes
// ======================================
$cmd = cmd::byString('#[Salon][Welcome Salon][Derniere fois Chrystel]#');
$Chrystel = $cmd->execCmd();
$cmd = cmd::byString('#[Salon][Welcome Salon][Derniere fois Manu]#');
$Manu = $cmd->execCmd();
$cmd = cmd::byString('#[Salon][Welcome Salon][Derniere fois Sophie]#');
$Sophie = $cmd->execCmd();
//
// Transformation en HHMM
// ======================
$Chrystelheure = date(HI,strtotime($Chrystel));
$Manuheure = date(HI,strtotime($Manu));
$Sophieheure = date(HI,strtotime($Sophie));
// Stockage dans une variable
// ==========================
$scenario->setData("HeureChrys",$Chrystelheure);
$scenario->setData("HeureManu",$Manuheure);
$scenario->setData("HeureSophie",$Sophieheure);
les variables XXheure sont par contre fausses ... : 171 ...
??
Re: Heure de la dernière communication.
ok j'ai trouvé ...ManuJ71 a écrit :J'ai même essayé en code, mais rien n'y fait ...
les variables Manu, chrystel et Sophie contiennent bien l'horodatage complet : 2017-04-05 17:34:39Code : Tout sélectionner
// Récupération des valeurs heures brutes // ====================================== $cmd = cmd::byString('#[Salon][Welcome Salon][Derniere fois Chrystel]#'); $Chrystel = $cmd->execCmd(); $cmd = cmd::byString('#[Salon][Welcome Salon][Derniere fois Manu]#'); $Manu = $cmd->execCmd(); $cmd = cmd::byString('#[Salon][Welcome Salon][Derniere fois Sophie]#'); $Sophie = $cmd->execCmd(); // // Transformation en HHMM // ====================== $Chrystelheure = date(HI,strtotime($Chrystel)); $Manuheure = date(HI,strtotime($Manu)); $Sophieheure = date(HI,strtotime($Sophie)); // Stockage dans une variable // ========================== $scenario->setData("HeureChrys",$Chrystelheure); $scenario->setData("HeureManu",$Manuheure); $scenario->setData("HeureSophie",$Sophieheure);
les variables XXheure sont par contre fausses ... : 171 ...
??
le format c'est pas HI majuscule mais Hi (H majuscule et i minuscule) et les mettre entre " .
$Chrystelheure = date("Hi",strtotime($Chrystel));
et ca fonctionne ... ! si ca peut aider ...
Encore merci de m'avoir mis sur la voie ...
Re: Heure de la dernière communication.
Essaye en faisant plutôt:
test = strtotime(#[Salon][Welcome Salon][Derniere fois Manu]#)
temp = date(Hi,test)
il me semble avoir eu des problèmes en utilisant date avec une variable qui dépendait d'une autre variable
test = strtotime(#[Salon][Welcome Salon][Derniere fois Manu]#)
temp = date(Hi,test)
il me semble avoir eu des problèmes en utilisant date avec une variable qui dépendait d'une autre variable
Jeedom sur vm esxi stretch
Principaux plugins: eibd, homebridge, maxcube, icalendar
Principaux plugins: eibd, homebridge, maxcube, icalendar
-
- Timide
- Messages : 125
- Inscription : 01 janv. 2017, 23:41
Re: Heure de la dernière communication.
Me revoilà,
Nouveaux équipements, nouvelles questions.
J'utilise le collectdate pour vérifier le bon fonctionnement de mes sondes de température 433.
Pas de problème, c'est bien la date de dernière communication qui change.
Je voulais faire la même chose avec mes capteurs xiaomi, par contre, je me suis rendu compte que ce n'est pas la date de dernière communication qui bouge, mais la date de dernière mise à jour ( j'ai une date de dernièr comm < date de mise à jour )
Y a t'il une fonction pour récupérer cette date de dernière mise à jour.
( Mon objectif est de faire une moyenne entre les 2 capteurs, en vérifiant avant que les 2 ont envoyé des données "il n'y a pas trop longtemps"
Merci
Nouveaux équipements, nouvelles questions.
J'utilise le collectdate pour vérifier le bon fonctionnement de mes sondes de température 433.
Pas de problème, c'est bien la date de dernière communication qui change.
Je voulais faire la même chose avec mes capteurs xiaomi, par contre, je me suis rendu compte que ce n'est pas la date de dernière communication qui bouge, mais la date de dernière mise à jour ( j'ai une date de dernièr comm < date de mise à jour )
Y a t'il une fonction pour récupérer cette date de dernière mise à jour.
( Mon objectif est de faire une moyenne entre les 2 capteurs, en vérifiant avant que les 2 ont envoyé des données "il n'y a pas trop longtemps"
Merci
Re: Heure de la dernière communication.
Bonjour,
je déterre un peu ce sujet, mais je suis devant une route en Y.
droite, gauche... je ne sais quelle solution choisir.
J'explique.
J'utilise actuellement dans un scénario :
strtotime('NOW')-strtotime(CollectDate(#[Chambre Parents][Capteur][Temp]#))>1800 => erreur
cependant, je ne comprenais pas j'avais beaucoup de remontée d'erreur.
Après quelques lectures et essais, je trouve aussi l'utilisation pour certain de "stateDuration" (durée depuis le dernier changement d'état):
stateDuration(#[Chambre Parents][Capteur][Temp]#)>1800 => erreur
J'ai pu aussi tester et le résultat obtenu est 'True' :
strtotime('NOW')-strtotime(CollectDate(#[Chambre Parents][Capteur][Temp]#)) <> stateDuration(#[Chambre Parents][Capteur][Temp]#)
Suite de mes investigations, je vois (comme dans l'image) qu'il y a une heure différente, ce qui confirme les écarts (des fois plus important) que j'ai pu obtenir durant mes essais. Je ne dis pas qu'une méthode est meilleure, que la défaillance se trouve sur le plugin, je cherche à comprendre et trouver le meilleur compromis. En espérant que ceci soit bien lu.
Il est possible que la communication est lieu, mais que la valeur n'ayant pas bougé, cela est considérer comme non nécessaire de la mettre à jour.
Donc le capteur envoie le package complet (je ne lui connais pas d'intelligence de tri => je communique sans transmettre de données), et du coup c'est Jeedom ou RFLink qui fait le tri des informations reçues. D'où un potentiel décalage, (nombre de fois et non à la marge), de plus de 1800s (soit 30mn)
Pour l'idée, c'est d'être sur que le capteur Temp/Hygro vit toujours. Si il communique c'est qu'il est alive, ou du moins avec assez de batterie (car c'est une option non mesurable sur les vieux matos). Sachant que le RFLink ne se déplace pas, et que les capteurs de temp non plus, on peut éliminer l'idée que la distance est l'option dégradante de communication.
Dans l'espoir que mon sujet attisera les curiosités et les réponses.
Belle journée.
je déterre un peu ce sujet, mais je suis devant une route en Y.
droite, gauche... je ne sais quelle solution choisir.
J'explique.
J'utilise actuellement dans un scénario :
strtotime('NOW')-strtotime(CollectDate(#[Chambre Parents][Capteur][Temp]#))>1800 => erreur
cependant, je ne comprenais pas j'avais beaucoup de remontée d'erreur.
Après quelques lectures et essais, je trouve aussi l'utilisation pour certain de "stateDuration" (durée depuis le dernier changement d'état):
stateDuration(#[Chambre Parents][Capteur][Temp]#)>1800 => erreur
J'ai pu aussi tester et le résultat obtenu est 'True' :
strtotime('NOW')-strtotime(CollectDate(#[Chambre Parents][Capteur][Temp]#)) <> stateDuration(#[Chambre Parents][Capteur][Temp]#)
Suite de mes investigations, je vois (comme dans l'image) qu'il y a une heure différente, ce qui confirme les écarts (des fois plus important) que j'ai pu obtenir durant mes essais. Je ne dis pas qu'une méthode est meilleure, que la défaillance se trouve sur le plugin, je cherche à comprendre et trouver le meilleur compromis. En espérant que ceci soit bien lu.
Il est possible que la communication est lieu, mais que la valeur n'ayant pas bougé, cela est considérer comme non nécessaire de la mettre à jour.
Donc le capteur envoie le package complet (je ne lui connais pas d'intelligence de tri => je communique sans transmettre de données), et du coup c'est Jeedom ou RFLink qui fait le tri des informations reçues. D'où un potentiel décalage, (nombre de fois et non à la marge), de plus de 1800s (soit 30mn)
Pour l'idée, c'est d'être sur que le capteur Temp/Hygro vit toujours. Si il communique c'est qu'il est alive, ou du moins avec assez de batterie (car c'est une option non mesurable sur les vieux matos). Sachant que le RFLink ne se déplace pas, et que les capteurs de temp non plus, on peut éliminer l'idée que la distance est l'option dégradante de communication.
Dans l'espoir que mon sujet attisera les curiosités et les réponses.
Belle journée.
Dernière édition par HeadsB le 05 oct. 2017, 14:41, édité 1 fois.
JeeDOM sur Debian 9 virtualisé sous Proxmox, ainsi qu'un Pi3.
RFLink/Xiaomi/BLEA et tous les satellites
Tjs l'envie d'apprendre...
RFLink/Xiaomi/BLEA et tous les satellites
Tjs l'envie d'apprendre...
Re: Heure de la dernière communication.
Bonjour,
strtotime('NOW')-strtotime(CollectDate(#[Chambre Parents][Capteur][Temp]#))>1800 => erreur (si pas d'info depuis 1800 secondes)
que tu veux ?
Tu es sûr que ce n'est pas
strtotime('NOW')-strtotime(CollectDate(#[Chambre Parents][Capteur][Temp]#))>1800 => erreur (si pas d'info depuis 1800 secondes)
que tu veux ?
Il y a 10 catégories de personnes, celles qui connaissent le binaire et les autres
.
.
Re: Heure de la dernière communication.
Bonjour,
C'est vrai que sur mon post, j'ai mis les signes à l'envers.
Mais le plus gros du problème n'est pas là.
Le focus est bien sur les différentes dates, et la différence entre strtotime et stateDuration.
En tout cas, merci pour ta réponse.
Belle journée.
Envoyé de mon ONEPLUS en utilisant mon index...
C'est vrai que sur mon post, j'ai mis les signes à l'envers.
Mais le plus gros du problème n'est pas là.
Le focus est bien sur les différentes dates, et la différence entre strtotime et stateDuration.
En tout cas, merci pour ta réponse.
Belle journée.
Envoyé de mon ONEPLUS en utilisant mon index...
JeeDOM sur Debian 9 virtualisé sous Proxmox, ainsi qu'un Pi3.
RFLink/Xiaomi/BLEA et tous les satellites
Tjs l'envie d'apprendre...
RFLink/Xiaomi/BLEA et tous les satellites
Tjs l'envie d'apprendre...
Re: Heure de la dernière communication.
Bonjour,
Pour essayer de répondre quand même à ta question, je surveille aussi mes sondes de température et j'utilise collectdate (date de la dernière valeur récupérée) et je n'ai jamais eu de faux positif (sonde rfxcom).
(#timestamp# - strtotime(collectdate(#[Jardin][Température Jardin][Température]#))) < 1800
== ok
Concernant les deux dates, il me semble que la date de valeur est la date du dernier changement de valeur. Concernant la mise à jour ou non des ces dates, c'est dépendant du plugin. Certains plugins ne mettent pas à jour la valeur de collecte si la valeur n'a pas changé (et donc date de collecte == date de valeur) d'autres (rfxcom) le font (et donc date de collecte != date de valeur).
Il peut y avoir un grand décalage entre les 2 et pour la surveillance des sondes le mieux est de prendre collectedate car si ta température ne varie pas, stateduration va rapidement déclencher des faux positifs (dans ton cas, pas de variation de température pendant 30mn)
Et pour finir collectdate n'a pas besoin que les données soient historisées.
Belle journée à toi aussi
Pour essayer de répondre quand même à ta question, je surveille aussi mes sondes de température et j'utilise collectdate (date de la dernière valeur récupérée) et je n'ai jamais eu de faux positif (sonde rfxcom).
(#timestamp# - strtotime(collectdate(#[Jardin][Température Jardin][Température]#))) < 1800
== ok
Concernant les deux dates, il me semble que la date de valeur est la date du dernier changement de valeur. Concernant la mise à jour ou non des ces dates, c'est dépendant du plugin. Certains plugins ne mettent pas à jour la valeur de collecte si la valeur n'a pas changé (et donc date de collecte == date de valeur) d'autres (rfxcom) le font (et donc date de collecte != date de valeur).
Il peut y avoir un grand décalage entre les 2 et pour la surveillance des sondes le mieux est de prendre collectedate car si ta température ne varie pas, stateduration va rapidement déclencher des faux positifs (dans ton cas, pas de variation de température pendant 30mn)
Et pour finir collectdate n'a pas besoin que les données soient historisées.
Belle journée à toi aussi
Il y a 10 catégories de personnes, celles qui connaissent le binaire et les autres
.
.
Re: Heure de la dernière communication.
Bonjour,
Merci pour le retour.
Après plusieurs investigations, j'ai remarqué que les valeurs des capteurs physiques étaient remontées et mises à jour, bien plus que les valeurs des virtuels.
En effet anciennement, pour ne pas perdre l’historique des relevés de températures, j'avais créé des virtuels qui archivaient l'historique.
Tjs dans le bon vieux temps, quand on changeait les piles du capteur, son ID change, et l'import de l'historique n'était pas possible.
Cela fonctionnait jusque là. Donc je n'avais pas remis le nez dedans.
Maintenant, que l'import de l'historique est possible, le virtuel n'a plus lieu d'être, et comme le dit un Major de Jeedom, "ce n'est pas bien de faire un virtuel d'un réel"...
Après toutes les modifications, je m'aperçois que tout fonctionne normalement.
Je vais donc laissé comme cela, même si j'ai relevé quelques soucis.
Par exemple: si on appelle ce capteur dans le scénario, si on change les piles, il faut prendre en compte celui-ci (le nouveau) dans le scénario. Si il est dans un graph, idem...
Merci en tout cas pour votre aide, et vos idées.
Belle journée.
Merci pour le retour.
Après plusieurs investigations, j'ai remarqué que les valeurs des capteurs physiques étaient remontées et mises à jour, bien plus que les valeurs des virtuels.
En effet anciennement, pour ne pas perdre l’historique des relevés de températures, j'avais créé des virtuels qui archivaient l'historique.
Tjs dans le bon vieux temps, quand on changeait les piles du capteur, son ID change, et l'import de l'historique n'était pas possible.
Cela fonctionnait jusque là. Donc je n'avais pas remis le nez dedans.
Maintenant, que l'import de l'historique est possible, le virtuel n'a plus lieu d'être, et comme le dit un Major de Jeedom, "ce n'est pas bien de faire un virtuel d'un réel"...
Après toutes les modifications, je m'aperçois que tout fonctionne normalement.
Je vais donc laissé comme cela, même si j'ai relevé quelques soucis.
Par exemple: si on appelle ce capteur dans le scénario, si on change les piles, il faut prendre en compte celui-ci (le nouveau) dans le scénario. Si il est dans un graph, idem...
Merci en tout cas pour votre aide, et vos idées.
Belle journée.
JeeDOM sur Debian 9 virtualisé sous Proxmox, ainsi qu'un Pi3.
RFLink/Xiaomi/BLEA et tous les satellites
Tjs l'envie d'apprendre...
RFLink/Xiaomi/BLEA et tous les satellites
Tjs l'envie d'apprendre...
Re: Heure de la dernière communication.
Hello,
Pourriez-vous poster un exemple de scénario ? Du coup on a quoi en déclencheur ? Une vérification tous les X minutes ? Merci !!!
Pourriez-vous poster un exemple de scénario ? Du coup on a quoi en déclencheur ? Une vérification tous les X minutes ? Merci !!!
Jeedomien depuis 2014
Rpi3 - SSD 32Go + Stick Aeon Gen5 + RfxTrx + Gateway Xiaomi
+ Rpi3 - SSD 32Go + Stick Aeon Gen5 en Jeelink
+ 40 Modules Zwave + 25 modules 433 + 10 modules Xiaomi Home + 5 Caméras.
Rpi3 - SSD 32Go + Stick Aeon Gen5 + RfxTrx + Gateway Xiaomi
+ Rpi3 - SSD 32Go + Stick Aeon Gen5 en Jeelink
+ 40 Modules Zwave + 25 modules 433 + 10 modules Xiaomi Home + 5 Caméras.
Qui est en ligne ?
Utilisateurs parcourant ce forum : Aucun utilisateur inscrit et 1 invité