@asgothian
Die Ausgabe bei mir wäre:
model:TYWB 4ch-RF
description:4 channel relay
modelZigbee:TS0004
type:Router
nwk:51465
manuf id:4417
manufacturer:_TZ3000_imaccztn
power:Mains (single phase)
app version:82
hard version:1
zcl version:3
stack version:0
date code:
configured:true
Ich kann die aber auch gerne ein Modul zum Testen zusenden ...
Meiner wird erkannt als:
Interview successful: {"friendly_name":"0xa4c1382c7d391236","model":"TYWB 4ch-RF","vendor":"MHCOZY","description":"4 channel relay","supported":true}
Lustig ist, dass z.B die Befehle zum Einschaltverhalten korrekt umgesetzt werden.
Leider nicht die Befehle um die Ein/Ausgänge zu schalten.
Laut Zigbee2MQTT-Beschreibung sollte "{"state_l1": "ON"} für "MHCOZY TYWB 4ch-RF" korrekt sein um das 1st Relais einzuschalten.
So wie ich verstanden haben arbeitet das Modul unter Zigbee2MQTT korrekt oder?
@mihas
Hallo. Ich habe das gleiche Problem wie du.
Unter keinem der 3 Mode lassen die die Relais sinnvoll bedienen.
Es schalten, genauso wie von dir beschrieben, mehrere Relais ein/aus.
Auch der Kauf einen weiteren Moduls brachte nur das gleiche Ergebnis.
Dabei ist es egal ob die die Relais per switch "state_l1" schalte oder den Befehl {"state_l1": "ON"} via "send_payload" aus IOB absende.
Anm.: Ich nutzte ZHA / Zigbee
@andreas_n
Sorry - bitte ignorieren (habe es auf github eingetragen)
@ciddi89
Ich habe einige exotische Datenpunkte, wofür es keinen Support in dem Adapter gibt.
Im Moment behelfe ich mich damit, diese Datenpunkte per Script auf Änderung zu überwachen.
Schöner wäre es natürlich, wenn es hierfür einen direkten Support mit dem Adaptertreiber geben würde. Wäre so was möglich?
Schade, das keiner eine Idee hat.
Ich hatte vermutet, dass dieses Problem (das Nichtwissen, ob ein Aktor geschaltet hat) auch für andere Anlagen von Interesse ist.
Evt. ist die Lösung aber auch zu einfach und ich sehe es einfach nicht. ( kommt schon mal vor)
@wolfgangfb
Bei mir ist es 0.5.0 Beta 8. (Läuft soweit aber ganz OK)
Wenn es noch wichtig ist....
Es ist eine neue Version (Zur Zeit noch Beta) herausgekommen.
Diese Version hat Module aus dem Internet geladen sodass alles wieder funktioniert. (Problem mit PlatformIO)
Besten Dank @Dutchman
Eines ist mir noch aufgefallen, was zwar die Funktion nicht beeinträchtigt aber unschön ist.
Im Log finde ich viele Einträge, dass die Verbindung zu ioBroker mehrfach aufgebaut und einzeln abgebaut werden. (Dies ist neu - wird wohl am Beta-Stand liegen . oder?)
[16:42:38][C][wifi:389]: Signal strength: -49 dB ▂▄▆█
[16:42:38][C][wifi:393]: Channel: 5
[16:42:38][C][wifi:394]: Subnet: 255.255.255.0
[16:42:38][C][wifi:395]: Gateway: 192.168.1.1
[16:42:38][C][wifi:396]: DNS1: 192.168.1.1
[16:42:38][C][wifi:397]: DNS2: 0.0.0.0
[16:42:38][D][api.connection:1050]: ESPHome Logs 2023.10.6 (192.168.1.95): Connected successfully
[16:42:38][C][logger:416]: Logger:
[16:42:38][C][logger:417]: Level: DEBUG
[16:42:38][C][logger:418]: Log Baud Rate: 0
[16:42:38][C][logger:420]: Hardware UART: UART0
[16:42:38][D][api:102]: Accepted 192.168.1.95
....
[16:42:39][D][api:102]: Accepted 192.168.1.95
[16:42:39][C][mdns:115]: mDNS:
[16:42:39][C][mdns:116]: Hostname: lifepo4-48vsolar1
[16:42:39][C][ota:097]: Over-The-Air Updates:
[16:42:39][C][ota:098]: Address: lifepo4-48vsolar1.local:3232
[16:42:39][C][ota:101]: Using Password.
[16:42:39][D][api:102]: Accepted 192.168.1.95
[16:42:39][C][api:139]: API Server:
[16:42:39][C][api:140]: Address: lifepo4-48vsolar1.local:6053
[16:42:39][C][api:142]: Using noise encryption: YES
[16:42:39][D][api.connection:1050]: ESPHome Logs 2023.10.6 (192.168.1.95): Connected successfully
[16:42:39][W][component:214]: Component api took a long time for an operation (0.05 s).
[16:42:39][W][component:215]: Components should block for at most 20-30ms.
[16:42:39][D][api.connection:1050]: ESPHome Logs 2023.10.6 (192.168.1.95): Connected successfully
[16:42:40][W][api.connection:103]: ESPHome Logs 2023.10.6 (192.168.1.95): Connection closed
[16:42:40][D][api:102]: Accepted 192.168.1.95
[16:42:40][W][api.connection:103]: ESPHome Logs 2023.10.6 (192.168.1.95): Connection closed
[16:42:40][D][api.connection:1050]: ESPHome Logs 2023.10.6 (192.168.1.95): Connected successfully
[16:42:40][D][api:102]: Accepted 192.168.1.95
[16:42:40][W][api.connection:103]: ESPHome Logs 2023.10.6 (192.168.1.95): Connection closed
[16:42:40][D][api.connection:1050]: ESPHome Logs 2023.10.6 (192.168.1.95): Connected successfully
[16:42:40][D][api:102]: Accepted 192.168.1.95
[16:42:40][W][api.connection:103]: ESPHome Logs 2023.10.6 (192.168.1.95): Connection closed
[16:42:40][D][api.connection:1050]: ESPHome Logs 2023.10.6 (192.168.1.95): Connected successfully
[16:42:40][D][api:102]: Accepted 192.168.1.95
[16:42:40][W][api.connection:103]: ESPHome Logs 2023.10.6 (192.168.1.95): Connection closed
[16:42:40][D][api.connection:1050]: ESPHome Logs 2023.10.6 (192.168.1.95): Connected successfully
[16:42:40][D][api:102]: Accepted 192.168.1.95
[16:42:40][W][api.connection:103]: ESPHome Logs 2023.10.6 (192.168.1.95): Connection closed
[16:42:40][W][component:214]: Component api took a long time for an operation (0.05 s).
[16:42:40][W][component:215]: Components should block for at most 20-30ms.
[16:42:41][D][api.connection:1050]: ESPHome Logs 2023.10.6 (192.168.1.95): Connected successfully
[16:42:41][D][api:102]: Accepted 192.168.1.95
[16:42:41][W][api.connection:103]: ESPHome Logs 2023.10.6 (192.168.1.95): Connection closed
[16:42:41][D][api.connection:1050]: ESPHome Logs 2023.10.6 (192.168.1.95): Connected successfully
[16:42:41][D][api:102]: Accepted 192.168.1.95
[16:42:41][W][api.connection:103]: ESPHome Logs 2023.10.6 (192.168.1.95): Connection closed
Hallo, gibt es eine Möglichkeit herauszubekommen, ob ein Datenpunkt nicht mit eine ACK bestätigt wurde. (Also z.B. ein Ausgang hat nicht geschaltet)?
Wird ein device schalte, dann wird das ACK-Bit zunächst auf false und später dann vom Adapter zurück auf true gesetzt. Ich nun möchte die Datenpunkte ermitteln, die nicht zurück auf true gesetzt worden sind.
Gespielt habe ich mit nachfolgende Ansatz: Ermittelt alle "Alias" Elemente, die eine Bestätigung erhalten haben. Dies ist aber nicht das was ich suche .... Evt. ist der Ansatz auch falsch .....
on({ id: new RegExp("alias\.0\.[_a-zA-Z0-9]{1,20}\.[_a-zA-Z0-9]{1,20}\.SET"),change: "ne", ack:true}, async (obj) => {
let value = obj.state.val;
let oldValue = obj.oldState.val;
log("ChkOnNak: deviceId: "+ obj.id + " old=" + oldValue+" -> " + value + " ack="+obj.state.ack);
});
@frana120500
Das Problem ist auch bei mir vorhanden. (PlatformIO zu alt)
Denke die korrekte Frage ins Forum lautet:
Wie aktualisiere ich PlatformIO für ESPhome
