Aller au contenu

jojo

Membres confirmés
 Afficher le profil  Parcourir son contenu

  • Compteur de contenus

    14 310

  • Inscription

  • Dernière visite

Messages posté(e)s par jojo

  3. Posté(e) · Report reply

    J'ai implémenté ta nouvelle version,  et pas de chauffage ce matin.

    Mais je ne comprends rien, car pas d'erreur au niveau de ton régulateur :

    skpt.png

    Mais je vois ceci dans l'historique de la HC3 :

    151a.png

     

    alors que je (crois) n'ai rien demandé et ne vois rien à propos du régulateur.

     

    ???

  7. Posté(e) · Report reply

    suite au redémarrage de GEA cette nuit (backup hebdo), le règle "Deads" m'a bien envoyé une notif => cool.

     

    Cela m'a fait pensé à un truc du coup.

    GEA n'exécute les actions que s'il y a modification dans les conditions (normal).

    => pour "Deads", il va regarder s'il y a un json de généré, mais, question, regarde-t-il si les id retournés sont différentes ? Cela expliquerait que si ids 100 et 101 sont rapportés comme morts, si ces ids deviennent 101 et 102, il ne voit pas de modif, donc pas d'actions ? une piste ?

  11. Posté(e) · Report reply

    1) Merci de te pencher sur le problème.

    Le module qui était mort hier

    • avait une interface z-wave
    • n'était pas parent, mais je suppose que son parent était mort également
    • était enable

    mais maintenant, il s'est réveillé tout seul ...

     

    Mais j'ai d'autres modules morts, donc j'ai pu tester ta requête: 

    http://192.168.x.y/api/devices?property=[dead,true]&enabled=true&interface=zwave&parentId=1

    dont voici le json : 

    array		[5]
	0		{19}
	1		{19}
	2		{19}
	3		{19}
	4		{19}
id	:	701
name	:	FGS223_Circulateurs
roomID	:	239
view		[0]
type	:	com.fibaro.zwaveDevice
baseType	:	com.fibaro.device
enabled	:		true
visible	:		false
isPlugin	:		false
parentId	:	1
viewXml	:		false
hasUIView	:		false
configXml	:		false
interfaces		[6]
	0	:	polling
	1	:	zwave	
	2	:	zwaveAssociation
	3	:	zwaveConfiguration
	4	:	zwaveMultiChannelAssociation
	5	:	zwaveSlaveRouting
properties		{42}
	categories		[1]
	configured	:		true
    dead	:		true
    deadReason	:	power
    deviceControlType	:	1
    deviceIcon	:	28
    deviceRole	:	Other
    deviceSpecificData	:	h'0000000000000c16
    deviceSpecificIdType	:	Serial Number
    deviceState	:	Configured
    endPointId	:	0
    icon		{0}
    lastWorkingRoute		[0]
    lastWorkingRouteRequestStatus	:	ok
    lastWorkingRouteRequestTimestamp	:	0
	lastWorkingRouteResponseTimestamp	:	1712044837
    log	:	
    logTemp	:	
    manufacturer	:	
    markAsDead	:		true
    model	:	
    neighborList		[4]
    neighborListRequestStatus	:	ok
    neighborListRequestTimestamp	:	0
    neighborListResponseTimestamp	:	1712044837
    nodeId	:	89
    parameters		[36]
    parametersTemplate	:	781
    pollingInterval	:	-1
    pollingTimeSec	:	0
    productInfo	:	1,15,2,3,16,0,3,4
    saveLogs	:		true
    securityLevel	:	
    securitySchemes		[0]
    serialNumber	:	h'0000000000000c16
    supportedDeviceRoles		[1]
    useTemplate	:		true
    userDescription	:	33\nCirculateurs chaufferie\nChaufferie\nON = On / OFF = Off\n20 40 41 42 43\nen fait installé avec 224\n
    zwaveCompany	:	Fibargroup
    zwaveInfo	:	3,4,5
    zwaveSoftwareVersion		{0}
    zwaveVersion	:	3.4
actions		{7}
created	:	1661610677
modified	:	1702381061
sortOrder	:	427

    J'espère que cette info t'aidra. => merci

     

    N.B. quand je teste si un module spécifique (même s'il n'est pas parent) est mort, ca fonctionne avec 

    {"Dead", <id module>}

     

  12. Posté(e) · Report reply

    Salut,

    Je me demande s'il n'y a pas un petit bug avec l'instruction "Deads".

    Voici ma règle 

    GEA.add ({"Deads"}, 0, "",
         {{"QuickApp", id["DEADS"], "Deads"},
          {"Email", "admin", "Réveil des noeuds morts via QA\nle #date# à #time#.", 
                             "Réveil des noeuds morts via QA"}})

    or j'ai un nœud mort, confirmé par le json 

    object		{19}
id	:	1140
name	:	Chauf_SdBRdC_Vanne
roomID	:	224
view		[2]
type	:	com.fibaro.hvacSystem
baseType	:	com.fibaro.device
...
properties		{62}
...		
configured	:		true
dead	:		true
deadReason	:	unknown
...

    et je ne reçois pas le mail...

  13. Posté(e) · Report reply

    j'ai fait c'est quelques mofifw dans le code, en espérant que ce soit ok

    vers ligne 1590 :     maxWakeUp           = 46800,     -- max duration (sec) of wakeUp      (Default: 46800 = 13 h)

    vers ligne 620 :     if abortOnErr and item.wakeUp > self.HMCF.maxWakeUp then

    vers ligne 718 :     if item.wakeUp then checkRange("wakeUp", item.wakeUp, 0, self.HMCF.maxWakeUp) end

     

    et du coup ma config

      HM:addHeater({id=162, wakeUp = 43200})

    est acceptée.

     

    Je verrai demain matin si mon radiateur chauffe.

  15. Posté(e) · Report reply

    Bonjour Maître :13:

    J'avais fait quelques tests rapides avec la régulation de mon bureau.

    Fort de cette expérience positive, je l'ai mis dans la salle de bains, et là j'ai du à nouveau faire preuve d'imagination vis-à-vis de ma femme.

    Voici la description des soucis:

    1) malgré une modification de la température mesurée

    42zj.png

    j'avais une erreur qui arrivait :

    [WARNING] Chauf_SdBRdC_Radiateur : No temp. update since 8h 00m

    et le radiateur ne fonctionnait plus sur la solution de replis que tu as mise en place (d'où les explications fumeuses que j'ai du trouver ...)

    Comme la sonde de température est une AeonTec aerq, je me suis dit que cela devait être le wakeup ...

    2) par défaut le wakeup est de 43200s (=12h) - c'est long mais ça me va.

    et, le régulateur passe sur OFF (ce serait cool que l'on puisse passer en solution de replis pour des erreur "compatibles")

    Voici le message d'erreur:

    9pzr.png

    En fait, le messaage d'eereur devrait être adapté. Dans ce cas, il faudrait :

    addHeater : 'wakeup'is out of lange [MinRange, MaxRange]

    et pour la seconde ligne :

    'wakeup' set to MaxRange sec

     

    Ce ne sont que des suggestions, tu auras peut-être une autre/meilleure idée ?

     

  25. Posté(e) · Report reply

    ah ok, je comprends mieux maintenant, c'est très logique en fait.

    Mais du coup, je ne comprends pas "d'un autre circuit".

    "un autre circuit" = un autre disjoncteur ? Car je croyais qu'on ne pouvais pas mélanger sur un même appareil différents disjoncteurs.

     

    J'avais donc +/- bien compris quand je disais que si on alimentait le FGS224 en 24V (= TBT) il pouvait commander un contact sec (= TBT).

     

    J'utilisais donc de manière risquée (pour ce qui était commandé par le contact sec) depuis des années des FGS221/2/4 alimentés en 220V (=BT) pour piloter des contacts secs (=TBT).

    Ceci va donc accélérer la migration de mes FGS224 vers les OUT1/2 des FGBS222.

×