device creation, wrong type

[rezzalex]

1 télécommande 1 bouton s'est créée correctement en switch light sous DZ, mes volets roulants se sont créés en Blinds + stop mais mes télécommandes 2 boutons (ON / OFF) se sont créées sous forme de volets ("blinds")

[FlyingDomotic]

Est-il possible d'avoir la valeur du champs "type" depuis le fichier configuration.yaml des télécommandes qui sont mal créées ? Pour info, le mapping est réalisé à partir des valeurs suivantes, fournies par DevMel : Button = 4096 Cover = 4097 CoverPosition = 4098 Switch = 4099

[rezzalex]

Pour les télécommandes 2 boutons " On/Off"créés en volet roulant dans DZ, le type est "4097"

[FlyingDomotic]

C'est donc bien en ligne avec les spécifications, mais pas en accord avec la réalité. Il serait intéressant de signaler l'erreur à DevMel, en précisant le type exact de la télécommande, afin qu'il corrigent l'erreur. En attendant, en changeant le type de 4097 en 4099 dans le fichier configuration.yaml, ça devrait fonctionner. Je vais regarder, par ailleurs, un moyen de forcer le type dans le fichier de configuration json.

[rezzalex]

OK, le type est bon dans DZ après modification du configuration.yaml.

Mais que peux y faire DevMel ?

[rezzalex]

après avoir éteint le plugin, supprimer mes devices DZ plugin airsend, forcer le fichier conf.yaml avec une télécommande en 4099, redémarrer le plug-in et essayer cette télécommande "modifiée" :

2023-01-05 09:12:58.935 Error: AirSend: Call to function 'onCommand' failed, exception details: 2023-01-05 09:12:58.938 Error: AirSend: Traceback (most recent call last): 2023-01-05 09:12:58.938 Error: AirSend: File "/opt/domoticz/userdata/plugins/AirSend/plugin.py", line 577, in onCommand 2023-01-05 09:12:58.938 Error: AirSend: _plugin.onCommand(Unit, Command, Level, Color) 2023-01-05 09:12:58.938 Error: AirSend: File "/opt/domoticz/userdata/plugins/AirSend/plugin.py", line 381, in onCommand 2023-01-05 09:12:58.938 Error: AirSend: Domoticz.Error("Don't know how to execute "+command+" for type " + str(airSendDeviceType)+" on "+device.Name) 2023-01-05 09:12:58.938 Error: AirSend: NameError: name 'command' is not defined

[FlyingDomotic]

Mais que peux y faire DevMel ?

Ce sont eux qui envoient le mauvais type de télécommande dans le fichier, si on veut le faire corriger, c'est par eux. Maintenant, on peut aussi forcer le type, ce qui devrait être possible bientôt. Mais on perd la facilité de la détermination automatique, ce qui est moche ;-)

[FlyingDomotic]

après avoir éteint le plugin, supprimer mes devices DZ plugin airsend, forcer le fichier conf.yaml avec une télécommande en 4099, redémarrer le plug-in et essayer cette télécommande "modifiée" :

2023-01-05 09:12:58.935 Error: AirSend: Call to function 'onCommand' failed, exception details: 2023-01-05 09:12:58.938 Error: AirSend: Traceback (most recent call last): 2023-01-05 09:12:58.938 Error: AirSend: File "/opt/domoticz/userdata/plugins/AirSend/plugin.py", line 577, in onCommand 2023-01-05 09:12:58.938 Error: AirSend: _plugin.onCommand(Unit, Command, Level, Color) 2023-01-05 09:12:58.938 Error: AirSend: File "/opt/domoticz/userdata/plugins/AirSend/plugin.py", line 381, in onCommand 2023-01-05 09:12:58.938 Error: AirSend: Domoticz.Error("Don't know how to execute "+command+" for type " + str(airSendDeviceType)+" on "+device.Name) 2023-01-05 09:12:58.938 Error: AirSend: NameError: name 'command' is not defined

L'erreur Python est corrigée, reste que ça va afficher maintenant un message d'erreur qu'il faudra traiter ... Assez probablement une commande non gérée qu'il faudra ajouter.

[rezzalex]

Avec la dernière version, Tjrs sur cette télécommande ON / OFF dont le type a été change manuellement, la commande ON a fonctionnée !

avec ce message d'erreur dans DZ :
2023-01-05 13:52:20.024 Error: AirSend: Don't know how to execute On for type 4099 on AirSend - coupe veille Box TV

le dispositif DZ ne change pas d'état, ce qui fait que DZ le crois tjrs éteint et envoi tjrs ON et jamais OFF :-(

[rezzalex]

Les dispositifs ON/OF dont le type n'a pas été forcé/changé dans le fichier de conf parviennent à envoyer un ON en appuyant sur "Volet Ouvert", mais pas de OFF en cas de "Volet fermé"

[FlyingDomotic]

C'est à priori corrigé en 0.0.8

[rezzalex]

TIcket ouvert chez Devmel pour le pb type de device

[rezzalex]

Les dispositifs ON/OF dont le type n'a pas été forcé/changé dans le fichier de conf parviennent à envoyer un ON en appuyant sur "Volet Ouvert", mais pas de OFF en cas de "Volet fermé"

tjrs présent sur le plugin 0.0.8, pour les 4097 et 4099 les 4008 ne fonctionnement pas, aucune erreur, voici les logs (avec niveau Extra Verbose du plugin) :

2023-01-05 15:50:01.987 AirSend: 008/AirSend - Volets est, 25455/127079: Command: 'Close', Level: 0, Color: 2023-01-05 15:50:01.969 Status: User: rezzalex (IP: 192.168.1.3) initiated a switch command (2236/AirSend - Volets est/Close)

Je précise que pour les volets, les commandes locale CURL fonctionnent

[FlyingDomotic]

Pour les types 4097 et 4099, est-ce qu'on a toujours un message d'erreur ? Lequel ? C'est bien un relais on/off qui est derrière ?

Pour le 4098, le souci est que le WebService ne raconte pas grand chose ...

Jeter un œil sur le fichier AirSendWebService.log dans le répertoire où le WebService est présent, il raconte ce qu'il envoie au module qui génère la commande.

Je n'ai pas trouvé de liste de commandes supportées par type de télécommande ... ni bien compris ce qui est retourné quand la commande n'est pas supportée.

Pour info, voici les types d'ordres que je connais : PING = 1 PROG = 2 UNPROG = 3 RESET = 4 STOP = 17 TOGGLE = 18 OFF = 19 ON = 20 CLOSE = 21 OPEN = 22 MIDDLE = 33 DOWN = 34 UP = 35 LEFT = 36 RIGHT = 37 USERPOSITION = 38

On peut tenter d'envoyer par CURL les différentes commandes, pour voir ce qui répond (ou pas).

[rezzalex]

Bonjour,

j'ai peut être une piste...

Dans le code ici, on dirait que la commande envoyée a l'airsend dans le cas de volets roulants est "Close" (21), et cela devrait être "DOWN" (34) :

Pour remonter les volets, cela doit être "UP"

[rezzalex]

et pour les 4099, la "lumière" du dispositif SwitchLight dans DZ ne s'allume pas lors que l'on envoi un "ON" ==> cela empêche probablement d'envoyer un OFF

[rezzalex]

Bonjour,

j'ai peut être une piste...

Dans le code ici, on dirait que la commande envoyée a l'airsend dans le cas de volets roulants est "Close" (21), et cela devrait être "DOWN" (34) :

Pour remonter les volets, cela doit être "UP"

Cela fonctionne pour les volets roulants, comme ca :

[rezzalex]

et pour les 4099, la "lumière" du dispositif SwitchLight dans DZ ne s'allume pas lors que l'on envoi un "ON" ==> cela empêche probablement d'envoyer un OFF

Pour tous les périphériqes, la commande pour changer l'état des périphériques DZ ne semble pas placée dans la bonne fonction :

device.Update(nValue=1,sValue = device.sValue) est placée dans la fonction def onDeviceModified(self, Unit) (ligne 445) et devrait 'etre placé dans la fonction def onCommand (ligne 341)

[rezzalex]

TIcket ouvert chez Devmel pour le pb type de device

DevMel ne pense pas que le pb vient de chez eux :

[FlyingDomotic]

Alors, j'ai réaligné l'ensemble des valeurs avec des constantes, ce qui a permis de corriger quelques erreurs.

J'ai aussi modifié les types de télécommandes (qui ont été vérifiées par DevMel ;-)

Pour tous les périphériqes, la commande pour changer l'état des périphériques DZ ne semblent pas placées dans la bonne fonction :

device.Update(nValue=1,sValue = device.sValue) est placé dans la fonction def onDeviceModified(self, Unit) (ligne 445) et devrait 'etre placé dans la fonction def onCommand (ligne 341)

Ben, pas trop en fait ... On reçoit ici les modifs faites à l'extérieur de Domoticz. C'est par ce biais qu'on détecte et traite les messages reçus par le callback php, qui eaux mêmes reçoivent les sequences radio reçues par AirSend. On ne doit traiter ici que ces messages.

Les modifs faites en interne (dans Domoticz) arrivent par onCommand.

Pour finir, il peut être habile de passer le debug à "Extra verbose" avant de relancer le plug-in pour avoir un peu plus de détails.

[rezzalex]

Bonsoir,

merci pour les modifs.

Mes volets sont créés en type DZ "BLIND" (4098). Ils devraient être crées en "Blind + Stop" (4099 ?), car ma télécommande d'origine le permet. en les changeant manuellement, la commande stop fonctionnet. Pouvez-vous détecter que la fonction STOP est présente dans l'Airsend ?

Les autres télécommandes On/Off sont bien en Switch light, mais le bug déja remonté est tjrs présent, Le dispositif DZ ne change pas d'état et envoi dont tout le temps une commande ON, le OFF devient impossible à envoyer.

Ma remarque précédente sur la place de la fonction device.Update(nValue=1,sValue = device.sValue) est basée sur l'observation du code du plugin RFplayer, qui fonctionne bien a ce niveau. Dans ce plugin, le code device.Update(nValue=1,sValue = device.sValue) est bien placé dans def onCommand Dans ce plugin, onDeviceModified n'est même pas présent.

J'avais modifié pour passer cette fonction dans def onCommand, et le dispositif DZ changeait alors d'état, permettant l'envoi de la commande OFF.

D'autre part, est-il possible d'avoir un icône par défaut différent de la "lumière": Celui-ci par ex :

[FlyingDomotic]

Concernant les types Domoticz, on a le type volet, qui possède juste montée/descente, volet pourcentage qui ajoute le pourcentage et volet+stop, qui ajoute stop au pourcentage et volet vénitien qui ajoute stop à montée/descente.

Si le type créé ne convient pas, il suffit juste de le changer (bouton "Modifier").

Concernant le type on/off, il n'y a pas de test préalable avant le passage d'un ordre. Il n'y a aucune raison qu'un type "Off" ne soit pas envoyé. C'est juste le type "bouton" qui bascule l'état en partant de la position actuelle.

Ce qui aiderait, c'est d'activer le debug sur le plug-in AirSend (Extra verbose), pour voir ce qui est reçu et émis exactement, et un extrait du log du web serveur, qui servira à voir ce que le service AirSend a bien compris.

Avec ces infos, il sera plus facile de voir ce qui ne va pas, et ce qui devrait être ajouté et/ou modifié.

[rezzalex]

Concernant le type on/off, il n'y a pas de test préalable avant le passage d'un ordre. Il n'y a aucune raison qu'un type "Off" ne soit pas envoyé. C'est juste le type "bouton" qui bascule l'état en partant de la position actuelle.

C'est bien le problème, le bouton DZ ne bascule pas d'état lorsque l'on clique dessus. Ainsi en re- cliquant dessus, DZ croit qu'il est tjrs "off" et envoit donc tjrs un "On".

Les logs en extra verbose :

Aucun log dans le airsend webservice

[FlyingDomotic]

Ok, j'ai trouvé. Dans ma configuration, la mise à jour des devices se fait par le retour de la commande AirSend envoyée par les volets. Il faut que je fasse une modif pour que la mise à jour soit réalisée localement dans le cas où le protocole n'est pas écouté ou dans le cas où le périf commandé ne renvoie pas d'état.

[rezzalex]

Ok, j'ai trouvé. Dans ma configuration, la mise à jour des devices se fait par le retour de la commande AirSend envoyée par les volets. Il faut que je fasse une modif pour que la mise à jour soit réalisée localement dans le cas où le protocole n'est pas écouté ou dans le cas où le périf commandé ne renvoie pas d'état.

Est-ce loin de ma 1ere suggestion de code, qq posts plus hauts ?

[FlyingDomotic]

La partie OnCommand est exécutée lorsqu'un utilisateur (ou un script) passe une commande. C'est là que les commandes sont envoyées à AirSend. Les feedbacks et les appuis sur les télécommandes sont récupérés par AirSend, et renvoyés par le callback php au device "AirSend event data", qui est détecté dans OnDeviceModified, puisque la modif est faite en dehors de Domoticz et envoyée en json (comme dans le cas du plug-in cité plus haut).

[rezzalex]

Bonjour, Merci, je comprends.

Dans mon cas, mes VR ne renvoient pas d'état, en effet. Mais si je comprends bien, écouter le protocole de mes VR permettrait de changer l'état des télécommandes DZ et de d'harmoniser leur état avec l'Airsend, c'est juste ? De plus, j'ai entendu dire que l'Airsend ne pouvait écouter qu'un seul protocol à la fois. Dans mon cas, j'utiliser actuellement l'Airsend pour 3 protocoles différents, et peut être plus à l'avenir...

Peut-être un Wiki un peu plus étendu sur la partie call back pourrait être utile :

• a quoi sert le call back ?

  • utiliser en retour d'état,
  • ou pas (en écoutant un autre protocole : des sondes de température et humidité Oregon par ex).

• comment le configurer selon les cas plus hauts ou comment s'en passer (configuration) ?

Je suis du coup preneur d'une MAJ du plug-in :-)

Encore merci

[FlyingDomotic]

C'est exactement ça.

Bon nombre de liaisons radio pour ce genre de récepteurs ne sont pas bi-directionnelles, ce qui fait qu'on envoie une commande "dans le vide", en espérant qu'elle sera bien reçue et exécutée.

Pour ceux qui sont bi-directionnelles, on a un retour de la bonne réception, ce qui assure que le récepteur a bien compris. De plus, dans certains cas, le récepteur envoie également d'autres informations sur la position/l'état. Par exemple, un état "ouvert" ou "fermé" quand un volet est complètement ouvert ou fermé.

En ce qui concerne les télécommandes associées aux récepteurs de façon générale, leurs actions sont déconnectées, et on ne sait pas comment ils modifient l'état du "truc" connecté.

De ce que j'ai compris, AirSend permet d'écouter, soit rien, soit un protocole 433 générique, soit un seul protocole particulier. Ce protocole est spécifié dans parameters/protocolToListen. Quand un callback est défini, le web service l'appelle à chaque réception de trame sur le protocole écouté. Ce callback en php envoie ce message en json dans le dispositif Domoticz nommé AirSend event data. Vu que l'envoi est extérieur à Domoticz, on le récupère dans onDeviceModified, et on met à jour le dispositif concerné dans Domoticz.

Concernant le plug-in, le paramétrage est simple : si on souhaite écouter un protocole AirSend, on met dans protocolToListen son numéro, et il faut aussi définir webServerFolder et webServerUrl pour que le plug-in sache où copier le callback et comment l’appeler. Si on ne souhaite pas écouter, on ne précise pas protocolToListen, webServerFolder et webServerUrl.

Concernant les retours d'état, leur envoi dépend du récepteur et de la façon dont AirSend les traite. Il faut tester pour voir ce qui est renvoyé ou pas. Pour ça, le debug extraVerbose est assez utile. On peut aussi regarder dans le dispositif AirSend event data où figure le dernier message reçu. Enfin, le log du web service est également instructif.

Pour répondre à la question

• a quoi sert le call back ?
  • utiliser en retour d'état,
  • ou pas (en écoutant un autre protocole : des sondes de température et humidité Oregon par ex).

La réponse stricte est "A écouter les trames d'un protocole". Selon ce qu'il retourne (qui dépend de la télécommande, du récepteur et de la programmation d'AirSend), on aura (ou pas) un retour d'état ou de status.

Tant que j'y suis, une petite explication concernant le mapping : il est possible que certains récepteurs écoutent plusieurs télécommandes. Il arrive également qu'AirSend crée sa propre télécommande (ce qui est en général le cas pour les protocoles bi-directionnels ou ceux qui ont un compteur associé). Mes volets Bubbendorf, par exemple, on une adresse pour la télécommande d'origine, une adresse pour la télécommande AirSend et une dernière pour mon boitier iDiamant. AirSend déclare "sa" télécommande dans le fichier configuration.yaml. J'ai crée un mapping vers cette télécommande pour celle d'origine et une seconde pour iDiamant, pour chaque volet. Le dispositif Domoticz Airsend d'origine est mis à jour par les retours des 3 télécommandes.

Pour terminer, de mon point de vue, sans retour d'état ni des télécommandes externes, on devrait plutôt utiliser des dispositifs Domoticz "bouton poussoir" qui ne mémorisent pas l'état, et ne donneront pas d'indications erronées sur l'état d'un dispositif.

Je vais ajouter quelques explications dans le README pour clarifier un peu ce type de paramétrage.

Je suis par contre intéressé par le retour de la dernière version du plug-in (0.0.11) qui devrait (hors mise à jour du README.md) être le bon.

[rezzalex]

avec la dernière version, les "interrupteurs" basculent maintenant correctement, mais les VR ne fonctionnement plus :

2023-01-09 15:53:24.090 Status: dzVents: Info: icone batterie: ------ Start internal script: icone batteries: Device: "Jauge Batteries (Panneaux solaires)", Index: 2186 2023-01-09 15:53:25.229 AirSend: 013/AirSend - Volets Salle à manger, 25455/122983: Command: 'Close', Level: 0, Color: 2023-01-09 15:53:25.233 AirSend: Local context: 2023-01-09 15:53:25.234 AirSend: ----> 'Devices' '{1: <Domoticz.Device object at 0x7fcfd84831f8>, 2: <Domoticz.Device object at 0x7fcfd8483290>, 3: <Domoticz.Device object at 0x7fcfd8483328>, 4: <Domoticz.Device object at 0x7fcfd84833c0>, 5: <Domoticz.Device object at 0x7fcfd8483458>, 6: <Domoticz.Device object at 0x7fcfd84834f0>, 7: <Domoticz.Device object at 0x7fcfd8483588>, 8: <Domoticz.Device object at 0x7fcfd8483620>, 9: <Domoticz.Device object at 0x7fcfd84836b8>, 10: <Domoticz.Device object at 0x7fcfd8483750>, 11: <Domoticz.Device object at 0x7fcfd84837e8>, 12: <Domoticz.Device object at 0x7fcfd8483880>, 13: <Domoticz.Device object at 0x7fcfd8483918>, 14: <Domoticz.Device object at 0x7fcfd84839b0>, 15: <Domoticz.Device object at 0x7fcfd8483a48>, 16: <Domoticz.Device object at 0x7fcfd8483ae0>, 17: <Domoticz.Device object at 0x7fcfd8483b78>, 18: <Domoticz.Device object at 0x7fcfd8483c10>, 19: <Domoticz.Device object at 0x7fcfd8483ca8>, 20: <Domoticz.Device object at 0x7fcfd8483d40>}' 2023-01-09 15:53:25.234 AirSend: ----> 'Domoticz' '<module 'Domoticz' (built-in)>' 2023-01-09 15:53:25.234 AirSend: ----> 'Images' '{}' 2023-01-09 15:53:25.234 AirSend: ----> 'Parameters' '{'HardwareID': 35, 'HomeFolder': '/opt/domoticz/userdata/plugins/AirSend/', 'StartupFolder': '/opt/domoticz/', 'UserDataFolder': '/opt/domoticz/userdata/', 'WebRoot': '', 'Database': '/opt/domoticz/userdata/domoticz.db', 'Language': 'fr', 'Version': '0.0.10', 'Author': 'Flying Domotic', 'Name': 'AirSend', 'Address': '', 'Port': '0', 'SerialPort': '', 'Username': '', 'Password': '', 'Key': 'AirSend', 'Mode1': 'AirSend.json', 'Mode2': '', 'Mode3': '', 'Mode4': '', 'Mode5': '', 'Mode6': 'Verbose+', 'DomoticzVersion': '2022.2 (build 14895)', 'DomoticzHash': 'fbac95755', 'DomoticzBuildTime': '2022-12-25 14:31:07'}' 2023-01-09 15:53:25.235 AirSend: ----> 'Settings' '{'DB_Version': '158', 'LightHistoryDays': '30', 'MeterDividerEnergy': '1000', 'MeterDividerGas': '100', 'MeterDividerWater': '100', 'RandomTimerFrame': '10', 'ElectricVoltage': '230', 'CM113DisplayType': '1', '5MinuteHistoryDays': '7', 'SensorTimeout': '60', 'SensorTimeoutNotification': '0', 'UseAutoUpdate': '1', 'UseAutoBackup': '1', 'CostEnergy': '1785', 'CostEnergyT2': '1785', 'CostGas': '6218', 'CostWater': '16473', 'UseEmailInNotifications': '0', 'EmailPort': '465', 'EmailAsAttachment': '1', 'DoorbellCommand': '0', 'SmartMeterType': '0', 'NotificationSensorInterval': '1800', 'NotificationSwitchInterval': '0', 'RemoteSharedPort': '6144', 'Language': 'fr', 'DashboardType': '0', 'MobileType': '0', 'WindUnit': '0', 'TempUnit': '0', 'SecStatus': '0', 'SecOnDelay': '30', 'AuthenticationMethod': '0', 'ReleaseChannel': '1', 'RaspCamParams': '-w 800 -h 600 -t 1', 'UVCParams': '-S80 -B128 -C128 -G80 -x800 -y600 -q100', 'AcceptNewHardware': '1', 'ZWavePollInterval': '3600', 'ZWaveEnableDebug': '0', 'ZWaveNetworkKey': '0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F, 0x10', 'ZWaveEnableNightlyNetworkHeal': '0', 'BatteryLowNotification': '20', 'AllowWidgetOrdering': '1', 'ActiveTimerPlan': '0', 'HideDisabledHardwareSensors': '0', 'WebTheme': 'element-dark', 'FloorplanPopupDelay': '750', 'FloorplanFullscreenMode': '1', 'FloorplanAnimateZoom': '1', 'FloorplanShowSensorValues': '1', 'FloorplanShowSwitchValues': '0', 'FloorplanShowSceneNames': '0', 'FloorplanRoomColour': 'Blue', 'FloorplanActiveOpacity': '25', 'FloorplanInactiveOpacity': '5', 'TempHome': '20', 'TempAway': '15', 'TempComfort': '22.0', 'DegreeDaysBaseTemperature': '19.0', 'HTTPURL': 'aHR0cDovL25hc2FkYW06MzAwMC9hc3Npc3RhbnQv', 'ShowUpdateEffect': '1', 'ShortLogInterval': '5', 'DisplayPowerUsageInkWhGraph': '1', 'SendErrorNotifications': '0', 'HTTPPostContentType': 'YXBwbGljYXRpb24vanNvbg==', 'SendErrorsAsNotification': '1', 'Location': '46.395676;6.623326', 'ClickatellEnabled': '0', 'ClickatellAPI': '0', 'ClickatellFrom': '0', 'ClickatellPassword': '0', 'ClickatellTo': '0', 'ClickatellUser': '0', 'EmailFrom': 'rezza@free.fr', 'EmailServer': 'smtp.free.fr', 'EmailTo': 'rezzalex@gmail.com', 'EmailPassword': 'WDdocFI5ck83TzMwZzh6Tw==', 'EmailUsername': 'cmV6emFAZnJlZS5mcg==', 'HTTPEnabled': '1', 'HTTPField1': '0', 'HTTPField2': '0', 'HTTPField3': '0', 'HTTPField4': '0', 'HTTPTo': '0', 'KodiIPAddress': '192.168.1.74', 'KodiEnabled': '0', 'KodiPort': '9777', 'KodiTimeToLive': '5', 'LmsPlayerMac': '0', 'LmsDuration': '5', 'LmsEnabled': '0', 'NMAAPI': '9d86094b6879c5e4c8725b9f75694fb97aed755c89e70803', 'NMAEnabled': '0', 'ProwlAPI': '0', 'ProwlEnabled': '0', 'PushALotAPI': '0', 'PushALotEnabled': '0', 'PushbulletAPI': 'o.ghvTylb61XdIoZ9FIbTXsxMmAH39tEeF', 'PushbulletEnabled': '0', 'PushoverAPI': '0', 'PushoverUser': '0', 'PushoverEnabled': '0', 'PushsaferEnabled': '0', 'WebUserName': 'cmV6emFsZXg=', 'WebLocalNetworks': 'nasadam;172.19.0.*;192.168.1.*;127.0.0.*;2a01:cb15:28c:2e00:*', 'SecPassword': 'e2be1a765190b65b15e2054be34c0db8', 'ProtectionPassword': 'd41d8cd98f00b204e9800998ecf8427e', 'OneWireSensorPollPeriod': '0', 'OneWireSwitchPollPeriod': '0', 'EnableEventScriptSystem': '1', 'Title': 'Domoticz', 'CostEnergyR1': '1000', 'CostEnergyR2': '1000', 'WeightUnit': '0', 'DisableDzVentsSystem': '0', 'DzVentsLogLevel': '1', 'LogEventScriptTrigger': '1', 'IFTTTEnabled': '0', 'EmailEnabled': '1', 'GCMEnabled': '1', 'TelegramEnabled': '0', 'IFTTTAPI': 'ZE5OekNoMzVpR0xPTVFFaHVaMktPcg==', 'MyDomoticzUserId': '0', 'MyDomoticzSubsystems': '0', 'HTTPPostData': 'ew0KICAgICJ1c2VyIjogInJlenphbGV4IiwNCiAgICAiY29tbWFuZCI6ICIjTUVTU0FHRSIsDQogICAgImJyb2FkY2FzdCI6IHRydWUNCn0=', 'HTTPPostHeaders': '0', 'PushsaferAPI': '0', 'PushsaferImage': '0', 'TelegramAPI': '584764421:AAHl080vuKdSNp0q0Sd72-KJEr6GJUQ2QQA', 'TelegramChat': '557377245', 'ZWaveAeotecBlinkEnabled': '0', 'ZWaveAssumeAwake': '0', 'ZWaveRetryTimeout': '3000', 'ZWavePerformReturnRoutes': '1', 'EventSystemLogFullURL': '1', 'FCMEnabled': '1', 'MaxElectricPower': '7500', 'ForecastHardwareID': '28', 'Unique_ID': 'dd980410-6e18-4232-8903-f331d9cb2d44', 'ShortLogAddOnlyNewValues': '0', 'AllowPlainBasicAuth': '1'}' 2023-01-09 15:53:25.235 AirSend: ----> '_plugin' '<plugin.BasePlugin object at 0x7fcfd84975f8>' 2023-01-09 15:53:25.235 AirSend: ----> 'json' '<module 'json' from '/usr/lib/python3.7/json/__init__.py'>' 2023-01-09 15:53:25.235 AirSend: ----> 'os' '<module 'os' from '/usr/lib/python3.7/os.py'>' 2023-01-09 15:53:25.236 AirSend: ----> 'requests' '<module 'requests' from '/usr/local/lib/python3.7/dist-packages/requests/__init__.py'>' 2023-01-09 15:53:25.236 AirSend: ----> 'yaml' '<module 'yaml' from '/usr/local/lib/python3.7/dist-packages/yaml/__init__.py'>' 2023-01-09 15:53:25.208 Status: User: rezzalex (IP: 192.168.1.5) initiated a switch command (2241/AirSend - Volets Salle à manger/Close) 2023-01-09 15:53:25.230 Error: AirSend: Call to function 'onCommand' failed, exception details: 2023-01-09 15:53:25.233 Error: AirSend: Traceback (most recent call last): 2023-01-09 15:53:25.233 Error: AirSend: File "/opt/domoticz/userdata/plugins/AirSend/plugin.py", line 658, in onCommand 2023-01-09 15:53:25.233 Error: AirSend: _plugin.onCommand(Unit, Command, Level, Color) 2023-01-09 15:53:25.233 Error: AirSend: File "/opt/domoticz/userdata/plugins/AirSend/plugin.py", line 471, in onCommand 2023-01-09 15:53:25.233 Error: AirSend: nValue = self.nValueClose 2023-01-09 15:53:25.233 Error: AirSend: AttributeError: 'BasePlugin' object has no attribute 'nValueClose'

[rezzalex]

la remontée des VR fonctionne en revanche bien. Est ce qu'on est reparti par erreur sur du "CLOSE" pour les VR alors que ca devrait être du "DOWN" ?

logs d'erreur en synthèse :

023-01-09 16:54:02.006 Error: AirSend: Call to function 'onCommand' failed, exception details: 2023-01-09 16:54:02.007 Error: AirSend: Traceback (most recent call last): 2023-01-09 16:54:02.007 Error: AirSend: File "/opt/domoticz/userdata/plugins/AirSend/plugin.py", line 658, in onCommand 2023-01-09 16:54:02.007 Error: AirSend: _plugin.onCommand(Unit, Command, Level, Color) 2023-01-09 16:54:02.007 Error: AirSend: File "/opt/domoticz/userdata/plugins/AirSend/plugin.py", line 471, in onCommand 2023-01-09 16:54:02.007 Error: AirSend: nValue = self.nValueClose 2023-01-09 16:54:02.007 Error: AirSend: AttributeError: 'BasePlugin' object has no attribute 'nValueClose'

[rezzalex]

Tant que j'y suis, une petite explication concernant le mapping : il est possible que certains récepteurs écoutent plusieurs télécommandes. Il arrive également qu'AirSend crée sa propre télécommande (ce qui est en général le cas pour les protocoles bi-directionnels ou ceux qui ont un compteur associé). Mes volets Bubbendorf, par exemple, on une adresse pour la télécommande d'origine, une adresse pour la télécommande AirSend et une dernière pour mon boitier iDiamant. AirSend déclare "sa" télécommande dans le fichier configuration.yaml. J'ai crée un mapping vers cette télécommande pour celle d'origine et une seconde pour iDiamant, pour chaque volet. Le dispositif Domoticz Airsend d'origine est mis à jour par les retours des 3 télécommandes.

Je pense être dans le même cas avec mes volets PROFALUX. J'ai physiquement une télécommande individuelle + une générale avec des groupes (télécommande Noé). Comment connaitre leurs identifiants ou leur code pour mettre ca dans le mapping ?

[FlyingDomotic]

la remontée des VR fonctionne en revanche bien. Est ce qu'on est reparti par erreur sur du "CLOSE" pour les VR alors que ca devrait être du "DOWN" ?

Non, c'est juste que Closed et Close ne sont pas la même chose ;-) Fixé en 0.0.12.

[FlyingDomotic]

Je pense être dans le même cas avec mes volets PROFALUX. J'ai physiquement une télécommande individuelle + une générale avec des groupes (télécommande Noé). Comment connaitre leurs identifiants ou leur code pour mettre ca dans le mapping ?

Écouter le protocole concerné et relever les identifiants dans les messages poussés par le callback. On a également une trace dans le log du web service AirSend. Si le log n'apparait pas, ouvrir une demande de support chez DevMel, ce sont eux qui gèrent ça.

[rezzalex]

la remontée des VR fonctionne en revanche bien. Est ce qu'on est reparti par erreur sur du "CLOSE" pour les VR alors que ca devrait être du "DOWN" ?

Non, c'est juste que Closed et Close ne sont pas la même chose ;-) Fixé en 0.0.12.

Tout bon pour les commandes, mais l'état des VR est "inversé", ca affiche "ouvert" quand on clique sur "fermer" et inversement

[FlyingDomotic]

Il faut certainement changer le type de dispositif Domoticz par des versions "inversé", par exemple .

[rezzalex]

Il faut certainement changer le type de dispositif Domoticz par des versions "inversé", par exemple .

J'ai essayé toutes les combinaisons que propose les dernières versions de DZ, sans succès.

Est-il possible de l'inverser dans le code du plugin ?

[rezzalex]

Bonjour @FlyingDomotic ,

tout fonctionne parfaitement pour mes volets avec les modifications suivantes :

Sauf dans le mode plan ou le statut affiché est le bon, mais il semble bizarre que cliquer sur le seul icone disponible en 1er (ouvert) ne fasse rien, il faut passer le curseur pour faire apparaitre la commande "close" et ensuite cliquer dessus.

Qu'en pensez-vous ?

Comme mes VR ne répondent pas au pourcentage d'ouverture, j'ai changé manuellement le type DZ en Venitian EU, pour me débarrasser du slider inutile.

[FlyingDomotic]

Ca confirme bien que le volet est inversé. Pour s'en convaincre, cliquer sur "Ouvert" et on aura un "Commuation Off", et "Commutation On" en cliquant sur "On". Malheureusement, il n'y a pas de "Volet vénitien inversé" dans Domoticz ... On peut, soit modifier le code d'origine, comme fait plus haut, sachant que les volets "standards" fonctionneront à l'envers, soit utiliser un des volet inversés, en "oubliant" le curseur. On peut attendre aussi un peu un version future qui devrait permettre de tout paramétrer (dès que j'aurais terminé le truc sur le feu en ce moment).

[rezzalex]

Il y a bien un réglage d'inversion dans DZ, pour tous les volets, y compris les "venitian EU", mais ne fonctionne tjrs pas.

Pensez-vous qu'il faille faire qq chose côté DZ ou de votre côté ?

J ai ouvert un ticket Coté DZ, actuellement en "pause" :

https://github.com/domoticz/domoticz/issues/5531

N'hésitez pas à y intervenir si cela vous semble pertinent.

Encore merci

[rezzalex]

Bonjour @FlyingDomotic , Avez-vous eu le temps de jeter un œil sur mon ticket DZ (lien dans le post précédent) ?

Merci

[FlyingDomotic]

Oui.

J'ai vérifié que le code du plug-in fonctionne dans le bon sens.

Ca fonctionne bien dans le bon sens chez moi avec 2 types de volets différents (Bubbendorf et AvosDims).

J'ai testé avec 2 versions stables différentes de Domoticz (2020.2 et 2022.1).

Je n'ai pas testé sur les dernières versions, qui ne sont pas assez stables (j'ai 400+ devices dans Domoticz sur 19 plug-ins). Et comme il y a eu des modifs récentes sur les volets dans ces versions, j'aurais tendance à penser que l'erreur pourrait se situer par là ...

[rezzalex]

Après vérifications, la 2022.1 date du 31 janvier de l'année dernière. la 2022.2 du 11 mai 2022. https://www.domoticz.com/wiki/Domoticz_versions_-_Commits#Current_Stable_release

Les gros changements sur les volets sont entre les deux : https://www.domoticz.com/wiki/Domoticz_version_table_V2022.1

J'oserais abuser en vous demandant de tester avec la 2022.2, qui est la dernière stable.

[FlyingDomotic]

Ce n'est pas abuser, ça ne fait qu'avancer un peu mes tests sur la 2022.2, qui, si vous suivez les forums français et anglais, semble pas encore très stable, ce qui est normal au vu du nombre de changements apportés à la version précédente ;-)

[FlyingDomotic]

Bon, j'ai testé avec la stable 2022.2 et la dernière dev (build 14964), avec Firefox et Brave, en ayant détruit les cookies, vidé le cache, ..., avec une database vide, et c'est pas terrible ...

Déjà, il y a 2 bugs dans la liste du matériel : 1) le type du plug-in dans la liste du matériel n'est pas correct 2) une fois cliqué sur le plug-in, le type ne remonte pas, et les paramètres ne sont pas affichés.

Ensuite, il semble effectivement que le switch "reverse position" ne fonctionne pas ..., ce qui est bête vu qu'il serait utile dans notre cas ... car le fonctionnement des volets a bien été inversé entre la 2022.1 et la 2022.2.

En ce qui me concerne, je vais encore attendre un peu avant de passer à la 2022.2 ;-) Ceci dit, c'est une façon de raisonner assez classique en informatique : attendre 6 mois après des modifs majeures, 1 mois après un patch mineur, ne prendre le risque de le passer tout de suite que s'il corrige un pb de sécurité grave qu'on pourrait avoir.

[rezzalex]

OK, Merci. ais-je des options manquantes ici ? /

Je vais débloquer le ticket coté DZ.

Merci pour les remarques sur la prudence des MAJ, mais j'avais envie des nouveautés récentes sur le matériel "Enphase" (prod électrique solaire)

[FlyingDomotic]

Non, les options sont bien présentes dans cette copie d'écran. Chez moi, je n'ai pas la partie basse de la fenêtre (elle est vide). Petite question : est ce que le device "AirSend plugin" a été ajouté en 2022.2 ou avec une version antérieure ?

[rezzalex]

Je l'ai ajouté en 2022 +++ (déjà des beta / release intermédiaires).

Gizmocuz a répondu que "le plugin devait être "réécrit" pour s'adapter avec la version actuelle, qui marche très bien"

https://github.com/domoticz/domoticz/issues/5531

DZ ne s'adaptera pas au plugin; donc ...

encore merci

[FlyingDomotic]

D'après la nouvelle doc, les commandes des volets ont bien été inversées en 2022.2 (close = 0 maintenant alors que les versions précédentes étaient à 100). Il faut donc détecter la version et adapter open/close.

[rezzalex]

La 2022.2 étant la dernière stable, pourquoi ne pas faire fonctionner le plugin exclusivement avec cette version ?

[FlyingDomotic]

La 2022.2 étant la dernière stable, pourquoi ne pas faire fonctionner le plugin exclusivement avec cette version ?

Ben, parce qu'il existe des gens qui se sont pas en dernière version ... Par exemple : moi !

Du coup, la dernière version n'inverse les volets que pour les versions de Domoticz >= 2022.2.

[rezzalex]

effectivement, avec un "Dummy Device Venitian EU" et les "URLs" du cloud Airsend associées aux actions monter et descente, les statuts des VR fonctionnent tout à fait normalement.