Passe par l’API REST en attendant
Sinon, tu peux utiliser Gladys + Node-RED
Bah l’idéal dans gladys serait d’avoir un paramétrage plus souple du mqtt comme sur l’ipx ici la partie broker donc on met en paramètre l’adresse du broker mqtt sur le réseau
Il y a « prise » => « commutateur » qui est fait pour ça
Bonjour @pierre-gilles,
J’ai réussi à piloter un des relais de l’ipx800 via node-red, par contre je n’arrives pas à avoir depuis l’ipx800 le retour d’état de l’interrupteur dans gladys
j’ai pourtant un debug qui me sembles correct
22/01/2022, 00:32:11node: f14f85a92afafbeb
IPX800_V5-1 : msg.payload : string[25]
“{”[IPX]Relay cmd 1":true}"
22/01/2022, 00:32:13node: f14f85a92afafbebIPX800_V5-1 : msg.payload : string[28]
“{”[IPX]Relay state 1":false}"
22/01/2022, 00:32:13node: cf703754e8389474msg.payload : string[3]
“off”
22/01/2022, 00:32:13node: 89b610539bda7d0dmsg.payload : string[3]
“off”
22/01/2022, 00:32:13node: e4dc354cc2860d26msg.payload : number
0
22/01/2022, 00:32:13node: 8f8275c29bb036c5gladys/device/mqtt:lampe/feature/mqtt:lampe/state : msg.payload : string[1]
“0”
22/01/2022, 00:32:13node: 4678ca9e7131d24cgladys/device/mqtt:lampe/feature/mqtt:lampe/state : msg.payload : string[1]
“0”
22/01/2022, 00:32:13node: 471e3ac46dc6fb17gladys/device/mqtt:lampe/feature/mqtt:lampe/state : msg.payload : string[26]
“{”[IPX]Relay cmd 1":false}"
22/01/2022, 00:32:13node: f14f85a92afafbebIPX800_V5-1 : msg.payload : string[26]
“{”[IPX]Relay cmd 1":false}"
22/01/2022, 00:34:58node: 8f8275c29bb036c5gladys/device/mqtt:lampe/feature/mqtt:lampe/state : msg.payload : string[1]
“0”
22/01/2022, 00:34:58node: 4678ca9e7131d24cgladys/device/mqtt:lampe/feature/mqtt:lampe/state : msg.payload : string[1]
“0”
22/01/2022, 00:34:59node: f14f85a92afafbebIPX800_V5-1 : msg.payload : string[26]
“{”[IPX]Relay cmd 1":false}"
22/01/2022, 00:34:59node: 471e3ac46dc6fb17gladys/device/mqtt:lampe/feature/mqtt:lampe/state : msg.payload : string[26]
“{”[IPX]Relay cmd 1":false}"
22/01/2022, 00:34:59node: f14f85a92afafbebIPX800_V5-1 : msg.payload : string[26]
“{”[IPX]Relay cmd 1":false}"
le flow graphique
et le flow json à importer :
[
{
“id”: “bd5facfbf1ab26d3”,
“type”: “tab”,
“label”: “Flow 1”,
“disabled”: false,
“info”: “”,
“env”: []
},
{
“id”: “305ea00bbfebcf19”,
“type”: “mqtt in”,
“z”: “bd5facfbf1ab26d3”,
“name”: “”,
“topic”: “gladys/device/mqtt:lampe/feature/mqtt:lampe/state”,
“qos”: “1”,
“datatype”: “auto”,
“broker”: “291914c5c9c68f02”,
“nl”: false,
“rap”: true,
“rh”: 0,
“inputs”: 0,
“x”: 250,
“y”: 160,
“wires”: [
[
“8f8275c29bb036c5”,
“813b7bb0cb97117d”
]
]
},
{
“id”: “8f8275c29bb036c5”,
“type”: “debug”,
“z”: “bd5facfbf1ab26d3”,
“name”: “”,
“active”: true,
“tosidebar”: true,
“console”: false,
“tostatus”: false,
“complete”: “false”,
“statusVal”: “”,
“statusType”: “auto”,
“x”: 530,
“y”: 220,
“wires”: []
},
{
“id”: “813b7bb0cb97117d”,
“type”: “switch”,
“z”: “bd5facfbf1ab26d3”,
“name”: “”,
“property”: “payload”,
“propertyType”: “msg”,
“rules”: [
{
“t”: “eq”,
“v”: “0”,
“vt”: “str”
},
{
“t”: “eq”,
“v”: “1”,
“vt”: “str”
}
],
“checkall”: “true”,
“repair”: false,
“outputs”: 2,
“x”: 570,
“y”: 160,
“wires”: [
[
“4678ca9e7131d24c”,
“ab804a690e9c0df6”
],
[
“6b92e7dfca6a6f56”,
“196ae944ec3423d2”
]
]
},
{
“id”: “8f7e7262bc6bf978”,
“type”: “mqtt out”,
“z”: “bd5facfbf1ab26d3”,
“name”: “IPX800_V5-1”,
“topic”: “IPX800_V5-1”,
“qos”: “1”,
“retain”: “true”,
“respTopic”: “”,
“contentType”: “”,
“userProps”: “”,
“correl”: “”,
“expiry”: “”,
“broker”: “291914c5c9c68f02”,
“x”: 1270,
“y”: 160,
“wires”: []
},
{
“id”: “4678ca9e7131d24c”,
“type”: “debug”,
“z”: “bd5facfbf1ab26d3”,
“name”: “”,
“active”: true,
“tosidebar”: true,
“console”: false,
“tostatus”: false,
“complete”: “false”,
“statusVal”: “”,
“statusType”: “auto”,
“x”: 750,
“y”: 100,
“wires”: []
},
{
“id”: “6b92e7dfca6a6f56”,
“type”: “debug”,
“z”: “bd5facfbf1ab26d3”,
“name”: “”,
“active”: true,
“tosidebar”: true,
“console”: false,
“tostatus”: false,
“complete”: “false”,
“statusVal”: “”,
“statusType”: “auto”,
“x”: 750,
“y”: 220,
“wires”: []
},
{
“id”: “ab804a690e9c0df6”,
“type”: “change”,
“z”: “bd5facfbf1ab26d3”,
“name”: “”,
“rules”: [
{
“t”: “change”,
“p”: “payload”,
“pt”: “msg”,
“from”: “0”,
“fromt”: “str”,
“to”: “{”[IPX]Relay cmd 1":false}",
“tot”: “str”
}
],
“action”: “”,
“property”: “”,
“from”: “”,
“to”: “”,
“reg”: false,
“x”: 780,
“y”: 140,
“wires”: [
[
“8f7e7262bc6bf978”,
“471e3ac46dc6fb17”
]
]
},
{
“id”: “196ae944ec3423d2”,
“type”: “change”,
“z”: “bd5facfbf1ab26d3”,
“name”: “”,
“rules”: [
{
“t”: “change”,
“p”: “payload”,
“pt”: “msg”,
“from”: “1”,
“fromt”: “str”,
“to”: “{”[IPX]Relay cmd 1":true}",
“tot”: “json”
}
],
“action”: “”,
“property”: “”,
“from”: “”,
“to”: “”,
“reg”: false,
“x”: 780,
“y”: 180,
“wires”: [
[
“8f7e7262bc6bf978”,
“5733ce634bba7c5e”
]
]
},
{
“id”: “471e3ac46dc6fb17”,
“type”: “debug”,
“z”: “bd5facfbf1ab26d3”,
“name”: “”,
“active”: true,
“tosidebar”: true,
“console”: false,
“tostatus”: false,
“complete”: “false”,
“statusVal”: “”,
“statusType”: “auto”,
“x”: 1010,
“y”: 120,
“wires”: []
},
{
“id”: “5733ce634bba7c5e”,
“type”: “debug”,
“z”: “bd5facfbf1ab26d3”,
“name”: “”,
“active”: true,
“tosidebar”: true,
“console”: false,
“tostatus”: false,
“complete”: “false”,
“statusVal”: “”,
“statusType”: “auto”,
“x”: 1010,
“y”: 220,
“wires”: []
},
{
“id”: “4c607c3838172c89”,
“type”: “function”,
“z”: “bd5facfbf1ab26d3”,
“name”: “Affiche Etat Relais”,
“func”: “var msg1,msg2,msg3,msg4,msg5,msg6,msg7,msg8;\n\nswitch (msg.payload) {\n case “{\”[IPX]Relay state 1\”:true}":\n msg1 = {payload:“on” };\n break;\n case “{\”[IPX]Relay state 1\":false}":\n msg1 = {payload:“off” };\n break;\n case “{\”[IPX]Relay state 2\":true}":\n msg2 = {payload:“on” };\n break;\n case “{\”[IPX]Relay state 2\":false}":\n msg2 = {payload:“off” };\n break; \n case “{\”[IPX]Relay state 3\":true}":\n msg3 = {payload:“on” };\n break;\n case “{\”[IPX]Relay state 3\":false}":\n msg3 = {payload:“off” };\n break; \n case “{\”[IPX]Relay state 4\":true}":\n msg4 = {payload:“on” };\n break;\n case “{\”[IPX]Relay state 4\":false}":\n msg4 = {payload:“off” };\n break;\n case “{\”[IPX]Relay state 5\":true}":\n msg5 = {payload:“on” };\n break;\n case “{\”[IPX]Relay state 5\":false}":\n msg5 = {payload:“off” };\n break;\n case “{\”[IPX]Relay state 6\":true}":\n msg6 = {payload:“on” };\n break;\n case “{\”[IPX]Relay state 6\":false}":\n msg6 = {payload:“off” };\n break;\n case “{\”[IPX]Relay state 7\":true}":\n msg7 = {payload:“on” };\n break;\n case “{\”[IPX]Relay state 7\":false}":\n msg7 = {payload:“off” };\n break;\n case “{\”[IPX]Relay state 8\":true}":\n msg8 = {payload:“on” };\n break;\n case “{\”[IPX]Relay state 8\":false}":\n msg8 = {payload:“off” };\n break;\n default:\n break;\n}\n\nreturn[msg1,msg2,msg3,msg4,msg5,msg6,msg7,msg8];\n",
“outputs”: 8,
“noerr”: 0,
“initialize”: “”,
“finalize”: “”,
“libs”: [],
“x”: 350,
“y”: 520,
“wires”: [
[
“7a2c02eed1eff9ac”,
“0449882499c60013”,
“cf703754e8389474”
],
[
“39798a670d4370ce”
],
[
“6d3908d16e32d7f9”
],
[
“91f0b8e3a8eb8406”
],
[
“f71432e31830af17”
],
[
“6ffa92a11ae4e5e3”
],
[
“cd738b08572ab6f2”
],
[
“48a9f0c127ea6c0c”
]
]
},
{
“id”: “dad62c88489febcb”,
“type”: “mqtt in”,
“z”: “bd5facfbf1ab26d3”,
“name”: “IPX800_V5-1”,
“topic”: “IPX800_V5-1”,
“qos”: “1”,
“datatype”: “auto”,
“broker”: “291914c5c9c68f02”,
“nl”: false,
“rap”: true,
“rh”: 0,
“inputs”: 0,
“x”: 130,
“y”: 520,
“wires”: [
[
“4c607c3838172c89”,
“f14f85a92afafbeb”
]
]
},
{
“id”: “f14f85a92afafbeb”,
“type”: “debug”,
“z”: “bd5facfbf1ab26d3”,
“name”: “”,
“active”: true,
“tosidebar”: true,
“console”: false,
“tostatus”: false,
“complete”: “payload”,
“targetType”: “msg”,
“statusVal”: “”,
“statusType”: “auto”,
“x”: 330,
“y”: 620,
“wires”: []
},
{
“id”: “7a2c02eed1eff9ac”,
“type”: “ui_text”,
“z”: “bd5facfbf1ab26d3”,
“group”: “df9ed293.78c83”,
“order”: 4,
“width”: 6,
“height”: 1,
“name”: " Etat Relais 1",
“label”: " Etat Relais 1",
“format”: “{{msg.payload}}”,
“layout”: “row-spread”,
“className”: “”,
“x”: 690,
“y”: 580,
“wires”: [],
“inputLabels”: [
“r1”
]
},
{
“id”: “39798a670d4370ce”,
“type”: “ui_text”,
“z”: “bd5facfbf1ab26d3”,
“group”: “df9ed293.78c83”,
“order”: 7,
“width”: 6,
“height”: 1,
“name”: " Etat Relais 2",
“label”: " Etat Relais 2",
“format”: “{{msg.payload}}”,
“layout”: “row-spread”,
“className”: “”,
“x”: 690,
“y”: 660,
“wires”: [],
“inputLabels”: [
“r2”
]
},
{
“id”: “6d3908d16e32d7f9”,
“type”: “ui_text”,
“z”: “bd5facfbf1ab26d3”,
“group”: “df9ed293.78c83”,
“order”: 10,
“width”: 6,
“height”: 1,
“name”: " Etat Relais 3",
“label”: " Etat Relais 3",
“format”: “{{msg.payload}}”,
“layout”: “row-spread”,
“className”: “”,
“x”: 690,
“y”: 700,
“wires”: [],
“inputLabels”: [
“r3”
]
},
{
“id”: “91f0b8e3a8eb8406”,
“type”: “ui_text”,
“z”: “bd5facfbf1ab26d3”,
“group”: “df9ed293.78c83”,
“order”: 13,
“width”: 6,
“height”: 1,
“name”: " Etat Relais 4",
“label”: " Etat Relais 4",
“format”: “{{msg.payload}}”,
“layout”: “row-spread”,
“className”: “”,
“x”: 690,
“y”: 740,
“wires”: [],
“inputLabels”: [
“r4”
]
},
{
“id”: “f71432e31830af17”,
“type”: “ui_text”,
“z”: “bd5facfbf1ab26d3”,
“group”: “df9ed293.78c83”,
“order”: 16,
“width”: 6,
“height”: 1,
“name”: " Etat Relais 5",
“label”: " Etat Relais 5",
“format”: “{{msg.payload}}”,
“layout”: “row-spread”,
“className”: “”,
“x”: 690,
“y”: 780,
“wires”: [],
“inputLabels”: [
“r5”
]
},
{
“id”: “6ffa92a11ae4e5e3”,
“type”: “ui_text”,
“z”: “bd5facfbf1ab26d3”,
“group”: “df9ed293.78c83”,
“order”: 19,
“width”: 6,
“height”: 1,
“name”: " Etat Relais 6",
“label”: " Etat Relais 6",
“format”: “{{msg.payload}}”,
“layout”: “row-spread”,
“className”: “”,
“x”: 690,
“y”: 820,
“wires”: [],
“inputLabels”: [
“r6”
]
},
{
“id”: “cd738b08572ab6f2”,
“type”: “ui_text”,
“z”: “bd5facfbf1ab26d3”,
“group”: “df9ed293.78c83”,
“order”: 22,
“width”: 6,
“height”: 1,
“name”: " Etat Relais 7",
“label”: " Etat Relais 7",
“format”: “{{msg.payload}}”,
“layout”: “row-spread”,
“className”: “”,
“x”: 690,
“y”: 860,
“wires”: [],
“inputLabels”: [
“r7”
]
},
{
“id”: “48a9f0c127ea6c0c”,
“type”: “ui_text”,
“z”: “bd5facfbf1ab26d3”,
“group”: “df9ed293.78c83”,
“order”: 25,
“width”: 6,
“height”: 1,
“name”: " Etat Relais 8",
“label”: " Etat Relais 8",
“format”: “{{msg.payload}}”,
“layout”: “row-spread”,
“className”: “”,
“x”: 690,
“y”: 900,
“wires”: [],
“inputLabels”: [
“r8”
]
},
{
“id”: “e48f93c4daf91058”,
“type”: “inject”,
“z”: “bd5facfbf1ab26d3”,
“name”: “[IPX]Relay cmd 1 = true “,
“props”: [
{
“p”: “topic”,
“vt”: “str”
},
{
“p”: “payload”
}
],
“repeat”: “”,
“crontab”: “”,
“once”: false,
“onceDelay”: 0.1,
“topic”: “IPX800_V5-1”,
“payload”: “{”[IPX]Relay cmd 1”:true}”,
“payloadType”: “str”,
“x”: 1060,
“y”: 80,
“wires”: [
[
“8f7e7262bc6bf978”,
“18f06c897243f285”
]
]
},
{
“id”: “5c014f61c640a7be”,
“type”: “inject”,
“z”: “bd5facfbf1ab26d3”,
“name”: “[IPX]Relay cmd 1 = false”,
“props”: [
{
“p”: “topic”,
“vt”: “str”
},
{
“p”: “payload”
}
],
“repeat”: “”,
“crontab”: “”,
“once”: false,
“onceDelay”: 0.1,
“topic”: “IPX800_V5-1”,
“payload”: “{”[IPX]Relay cmd 1":false}",
“payloadType”: “str”,
“x”: 1070,
“y”: 260,
“wires”: [
[
“8f7e7262bc6bf978”,
“824df8aab3cb60a6”
]
]
},
{
“id”: “824df8aab3cb60a6”,
“type”: “debug”,
“z”: “bd5facfbf1ab26d3”,
“name”: “”,
“active”: true,
“tosidebar”: true,
“console”: false,
“tostatus”: false,
“complete”: “false”,
“statusVal”: “”,
“statusType”: “auto”,
“x”: 1290,
“y”: 260,
“wires”: []
},
{
“id”: “18f06c897243f285”,
“type”: “debug”,
“z”: “bd5facfbf1ab26d3”,
“name”: “”,
“active”: true,
“tosidebar”: true,
“console”: false,
“tostatus”: false,
“complete”: “false”,
“statusVal”: “”,
“statusType”: “auto”,
“x”: 1270,
“y”: 80,
“wires”: []
},
{
“id”: “f7ebc07a077abf6c”,
“type”: “mqtt out”,
“z”: “bd5facfbf1ab26d3”,
“name”: “gladys”,
“topic”: “gladys/device/mqtt:lampe/feature/mqtt:lampe/state”,
“qos”: “1”,
“retain”: “true”,
“respTopic”: “”,
“contentType”: “”,
“userProps”: “”,
“correl”: “”,
“expiry”: “”,
“broker”: “291914c5c9c68f02”,
“x”: 1430,
“y”: 520,
“wires”: []
},
{
“id”: “0449882499c60013”,
“type”: “switch”,
“z”: “bd5facfbf1ab26d3”,
“name”: “”,
“property”: “payload”,
“propertyType”: “msg”,
“rules”: [
{
“t”: “eq”,
“v”: “on”,
“vt”: “str”
},
{
“t”: “eq”,
“v”: “off”,
“vt”: “str”
}
],
“checkall”: “true”,
“repair”: false,
“outputs”: 2,
“x”: 810,
“y”: 520,
“wires”: [
[
“2ff286aacb794830”,
“eeeb4703a6ae4e8d”
],
[
“26611eefe03f44f0”,
“89b610539bda7d0d”
]
]
},
{
“id”: “2ff286aacb794830”,
“type”: “change”,
“z”: “bd5facfbf1ab26d3”,
“name”: “”,
“rules”: [
{
“t”: “change”,
“p”: “payload”,
“pt”: “msg”,
“from”: “on”,
“fromt”: “str”,
“to”: “1”,
“tot”: “num”
}
],
“action”: “”,
“property”: “”,
“from”: “”,
“to”: “”,
“reg”: false,
“x”: 1020,
“y”: 500,
“wires”: [
[
“f7ebc07a077abf6c”,
“8d19143d84685d18”
]
]
},
{
“id”: “26611eefe03f44f0”,
“type”: “change”,
“z”: “bd5facfbf1ab26d3”,
“name”: “”,
“rules”: [
{
“t”: “change”,
“p”: “payload”,
“pt”: “msg”,
“from”: “off”,
“fromt”: “str”,
“to”: “0”,
“tot”: “num”
}
],
“action”: “”,
“property”: “”,
“from”: “”,
“to”: “”,
“reg”: false,
“x”: 1020,
“y”: 540,
“wires”: [
[
“f7ebc07a077abf6c”,
“e4dc354cc2860d26”
]
]
},
{
“id”: “cf703754e8389474”,
“type”: “debug”,
“z”: “bd5facfbf1ab26d3”,
“name”: “”,
“active”: true,
“tosidebar”: true,
“console”: false,
“tostatus”: false,
“complete”: “false”,
“statusVal”: “”,
“statusType”: “auto”,
“x”: 770,
“y”: 460,
“wires”: []
},
{
“id”: “eeeb4703a6ae4e8d”,
“type”: “debug”,
“z”: “bd5facfbf1ab26d3”,
“name”: “”,
“active”: true,
“tosidebar”: true,
“console”: false,
“tostatus”: false,
“complete”: “false”,
“statusVal”: “”,
“statusType”: “auto”,
“x”: 990,
“y”: 460,
“wires”: []
},
{
“id”: “89b610539bda7d0d”,
“type”: “debug”,
“z”: “bd5facfbf1ab26d3”,
“name”: “”,
“active”: true,
“tosidebar”: true,
“console”: false,
“tostatus”: false,
“complete”: “false”,
“statusVal”: “”,
“statusType”: “auto”,
“x”: 990,
“y”: 580,
“wires”: []
},
{
“id”: “8d19143d84685d18”,
“type”: “debug”,
“z”: “bd5facfbf1ab26d3”,
“name”: “”,
“active”: true,
“tosidebar”: true,
“console”: false,
“tostatus”: false,
“complete”: “false”,
“statusVal”: “”,
“statusType”: “auto”,
“x”: 1230,
“y”: 460,
“wires”: []
},
{
“id”: “e4dc354cc2860d26”,
“type”: “debug”,
“z”: “bd5facfbf1ab26d3”,
“name”: “”,
“active”: true,
“tosidebar”: true,
“console”: false,
“tostatus”: false,
“complete”: “false”,
“statusVal”: “”,
“statusType”: “auto”,
“x”: 1230,
“y”: 580,
“wires”: []
},
{
“id”: “ce0b75e88aa679cc”,
“type”: “inject”,
“z”: “bd5facfbf1ab26d3”,
“name”: “gladys/device/mqtt:lampe/feature/mqtt:lampe/state”,
“props”: [
{
“p”: “payload”
},
{
“p”: “topic”,
“vt”: “str”
}
],
“repeat”: “”,
“crontab”: “”,
“once”: false,
“onceDelay”: 0.1,
“topic”: “gladys/device/mqtt:lampe/feature/mqtt:lampe/state”,
“payload”: “0”,
“payloadType”: “str”,
“x”: 1150,
“y”: 640,
“wires”: [
[
“f7ebc07a077abf6c”
]
]
},
{
“id”: “19eb9b651728d044”,
“type”: “inject”,
“z”: “bd5facfbf1ab26d3”,
“name”: “gladys/device/mqtt:lampe/feature/mqtt:lampe/state”,
“props”: [
{
“p”: “topic”,
“vt”: “str”
},
{
“p”: “payload”
}
],
“repeat”: “”,
“crontab”: “”,
“once”: false,
“onceDelay”: 0.1,
“topic”: “gladys/device/mqtt:lampe/feature/mqtt:lampe/state”,
“payload”: “1”,
“payloadType”: “str”,
“x”: 1130,
“y”: 400,
“wires”: [
[
“f7ebc07a077abf6c”
]
]
},
{
“id”: “291914c5c9c68f02”,
“type”: “mqtt-broker”,
“name”: “mqtt://localhost”,
“broker”: “mqtt://localhost”,
“port”: “1883”,
“clientid”: “”,
“autoConnect”: true,
“usetls”: false,
“protocolVersion”: “4”,
“keepalive”: “60”,
“cleansession”: true,
“birthTopic”: “”,
“birthQos”: “0”,
“birthPayload”: “”,
“birthMsg”: {},
“closeTopic”: “”,
“closeQos”: “0”,
“closePayload”: “”,
“closeMsg”: {},
“willTopic”: “”,
“willQos”: “0”,
“willPayload”: “”,
“willMsg”: {},
“sessionExpiry”: “”
},
{
“id”: “df9ed293.78c83”,
“type”: “ui_group”,
“name”: “Relais”,
“tab”: “4414d280.f20c4c”,
“order”: 1,
“disp”: true,
“width”: “12”,
“collapse”: true,
“className”: “”
},
{
“id”: “4414d280.f20c4c”,
“type”: “ui_tab”,
“name”: “IPX800_V5 Dashboard”,
“icon”: “dashboard”,
“disabled”: false,
“hidden”: false
}
]
j’ai loupé quelque chose ?
Bonjour @pierre-gilles,
En fait je crois que la problématique avec le mqtt dans ce cas est lié au fait de ne pas avoir de possibilité de mettre un élément en suscribe seul ou en publish seul et ne pas pouvoir lier des éléments entre eux.
Par exemple, dans gladys je déclare un commutateur, je veux que ce commutateur soit lié au relais de mon ipx cela marches si je clique sur le commutateur dans gladys le relais est activé, par contre si le relais est désactivé par un autre contrôle, j’ai pas de retour de l’état du relais au niveau du commutateur dans le dashboard de gladys !
Bonjour,
C’est parce que le topic d’écoute de Gladys n’est pas le même.
Tu dois envoyer l’état du device sur le topic que Gladys te propose quand tu coches la case ‘oui, ce capteur ne fait qu’envoyer des données…’
Oui mais on passe d’un Publish à un All (Publish/Suscribe) alors qu’en fait il faudrait
Je confirme ce que dit @GBoulvin, tu peux utiliser les topics MQTT dans les deux sens, même si le périphérique n’est pas un capteur.
L’API MQTT de Gladys est décrite ici:
Et fonctionne dans les deux sens
Bonsoir a tous
Avec Node Red et RFlink, je n’ai pas de retour d’état dans le dashboard, quand j’utilise ma télécommande pour actionner ma prise 433MHZ, alors que du dashboard, quand j’actionne cette prise forcement ça fonctionne puisque je clique dessus. Est ce que l’on est sur le meme probleme que cce66?
Oui mais je ne vois pas comment la distinction s’opères si c’est le même topic pour le suscribe et pour le publish et qu’il n’y ait pas de bouclage
exemple ici le commutateur, quel est le suscribe et quel est le publish ? si c’est la même valeur je pense que cela pose problème !
gladys/device/mqtt:commutateur/feature/mqtt:commutateur/state
Le topic pour publish une nouvelle valeur de l’extérieur de Gladys vers Gladys:
gladys/master/device/:device_external_id/feature/:device_feature_external_id/state
Le topic a subscribe pour recevoir des changements d’états de l’extérieur de Gladys:
gladys/device/:device_external_id/feature/:device_feature_external_id/state
Si tu remarque bien dans le nom du topic, il y a le préfix “gladys” toujours pour éviter les interférence
avec d’autres systèmes, et ensuite en premier il y a toujours le destinataire du message:
Je pense qu’il doit y avoir quelque chose de mal expliqué quelque part parce que beaucoup ne comprennent pas comment ça fonctionne alors que pour moi c’est clair comme de l’eau de roche
Le problème c’est la compréhension de la façon dont c’est formulé !
Donc en fait device est « publish » et « master » est « suscribe » c’est bien cela ? Ce serait peut-être plus compréhensible de les appeler « Publish » et « Suscribe » dans ce cas, on piges mieux le rôle et c’est plus proche du fonctionnement MQTT
Mais peut-être j’ai pas encore compris comment cela fonctionnes !!!
Je pense que cela vient du fait que tu vois gladys/mqtt comme une seule entité et on ne voit plus le fonctionnement client/broker/client ou le client est publish/fournisseur de données et/ou suscribe/abonné à une donnée et le broker juste transmetteur des données
Il n’y a pas vraiment de sens…
Tout dépend de quelle côté tu parles, comme tu dis, Gladys et ton device peut autant être un publisher qu’un subscriber.
donc c’est un publish, le capteur ne fait qu’envoyer des données et le topic est
gladys/master/device/mqtt:commutateur/feature/mqtt:commutateur/state
Un objet externe si il veut recevoir les données de cet objet doit s’abonner au topic
« gladys/master/device/mqtt:commutateur/feature/mqtt:commutateur/state »
gladys/device/mqtt:commutateur/feature/mqtt:commutateur/state
Un objet externe si il veut recevoir les données de cet objet doit s’abonner au topic
« gladys/master/device/mqtt:commutateur/feature/mqtt:commutateur/state »
mais
s’il veut lui en envoyer devra l’envoyer sur le topic:
« gladys/device/mqtt:commutateur/feature/mqtt:commutateur/state »
si c’est cela je te confirme c’est capillarotracté !
Non c’est l’inverse de ce que tu dis (ou alors les copier coller sont dans le mauvais sens
Euh c’est pas logique, pour moi on valide SI le capteur ne fait qu’envoyer des données !
Donc là le mqtt est “gladys/device” quand il reçoit ET envoie et “gladys/master” quand il envoie seulement !
D’autre part, c’est pas possible d’avoir des valeurs booléennes pour les valeur min/max ?
Ici, on se place du point de vue de Gladys. Soit elle envoie une commande à un device, soit elle en reçoit une. Dans le premier cas, Gladys le publie sur Gladys/device (à destination du device, donc). Dans le second cas, c’est le device qui publie sur Gladys/master (à destination de Gladys cette fois), pour faire un retour d’état par exemple.
Il faut bien voir que ces deux “adresses” sont fonctionnelles (avec chacune leur rôle décrit ci-avant) quelle que soit la position du switch “Est-ce un capteur ?”.
Ce switch n’est là que pour essayer de faciliter l’intégration des capteurs ou actionneurs. La plupart des périphériques faisant l’un ou l’autre.
Dans ton cas, avec un périphérique faisant les deux (pilotage + retour d’état), il te faut les deux “adresses” susmentionnées. La position du switch sur cette page ne changera rien au fonctionnement des deux adresses, c’est juste un élément visuel.
Ok donc en fait :
gladys/device/mqtt:commutateur/feature/mqtt:commutateur/state
quand gladys publie, le topic sur mosquito c’est gladys et il y a en clés
device/commutateur/feature
device/commutateur/state
gladys/master/device/mqtt:commutateur/feature/mqtt:commutateur/state
quand gladys reçoit, le topic sur mosquito c’est toujours gladys et il y a en clés
master/commutateur/feature
master/commutateur/state
En fait c’est le coté device/master(car on a pas d’indication du sens d’envoi des données) qui trompe , slave/master (pas top) ou publish/suscribe (plus cohérent car cela indique le sens de l’envoi des données de façon implicite car le « device » comme « master » est à la fois master et slave dans le comportement !
Dans ce cas je pense que tout le monde s’accordera pour dire qu’il faudrait que les 2 adresses soit affichées de base et que si on coche “Est-ce un capteur ?” seule la ligne correspondante s’affiche !
Effectivement c’est quand implemente dans node-red qu’il faut faire attention à bien mettre dans les objets mqtt la bonne ligne !
Sur le fond, je suis assez d’accord avec ton analyse.
Néanmoins, dans notre cas, avec Gladys, on peut faire l’hypothèse que c’est notre point central (box domotique) qui pilote le reste et qui gère tout l’aspect logique/ordonnancement. Dans ce contexte, il est assez logique de nommer ce nœud principal « master ».
Je ne veux pas trop m’avancer, mais je pense que c’est la logique qui a menée à choisir ces dénominations.
Je plussois cette partie, il me semble que ce bouton soit régulièrement source d’incompréhension sur le forum. Il faudrait peut-être créer un autre topic pour en discuter ?
Oui si effectivement gladys et mosquitto sont hébergés sur la même machine on peut le voir comme un point central mais le serveur mosquitto deployé par gladys dans la machine sur lequel il tourne fait également office de serveur pour d’autres clients qui ne passe pas par gladys et si gladys passe par un autre serveur mosquitto (ce qui est possible puisque paramétrable, par exemple chez moi j’ai un autre nuc sur lequel est hébergé Home-assistant sur lequel tourne mosquitto). Et si le noeud principal est « master » la logique aurait voulu que les devices soient …slave !
Je confirme j’ai mis un bout de temps à comprendre ce point là alors que j’ai déployé sans problème un flow node-red sur home-assistant qui interagis avec mon module domotique IPX800V5 (ce module intègre des objets mqtt « suscribe » et « publish »).