Antworten
Dez 09, 2017 - 06:05
Früher haben alle befehle die du angibst mit altem gateway funktioniert und dann kam auch eine antwort im browser.
Mit V5 plus ist das bei mir auch so wie bei dir, allerdings kannst du die get states auch im config tool ansehen unter debug.
Ich verwende es nicht, habe damals einige befehle getestet....wichtig ist ob du die befehle umsetzen kannst mit SetVar oder
angelernte geräte im gateway schalten kannnst, intertechno rs2w usw.
Wenn das klappt dann reicht es normal aus....es gibt schon lange zeit nichts neues von der gateway api.
Auf der mediola seite kann man es aber anfordern....zumindest hersteller....ob da dann etwas anderes ist als dieses dokument muss mediola sagen.
Dez 09, 2017 - 07:55
Von auf 09.12.2017 09:28:28 | Gefällt mir (0) | Melden
mit dem o.g. Modul funktionieren Abrufe?
kannst Du sehen, wie der http-request für ein 'GetStates' ist? Ich wollte mir was bauen, um den Status der HM-Koponenten (Batterie etc) abzurufen und wollte nicht jede Menge Tasks erstellen ...
Von auf 09.12.2017 11:09:30 | Gefällt mir (0) | Melden
Ich schaue mir das später mal an nutzte das aber bisher nur zum Schalten und Homematic läuft bei mir über die CCU. Ist ja etwas blöd wenn man den Status immer pullen muss ich kenne aber bisher auch keine Möglichkeit wie man das so mit einem AIO Gateway einrichtet das eine Status Aktualisierung automatisch erfolgt. Was willst Du genau machen in zyklischen Intervall von der extern die Variablen des AIO Gateways abrufen? Das dumme ist ich kann das selber nicht testen da ich kein V5 Plus besitze und sich da anscheinend auch manche Abfragen geändert haben. Ich nutzte noch ein V4 das reicht mir aus.
Von auf 09.12.2017 11:25:01 | Gefällt mir (0) | Melden
Erstmal wollte ich den Status vom HM-Komponenten (Batterie etc) feststellen und ggfs. auch Zeitpunkt der letzen Kommunikation festhalten.
Von auf 09.12.2017 11:41:40 | Gefällt mir (0) | Melden
wenn du dort besser nachschaust...
https://github.com/Wolbolar/IPSymconAIOGateway
wirst du sehen das der status der geräte nicht implementiert ist mit dem simcon modul :)
ich denke ist besser du schreibst den support von mediola direkt an oder wartest bis sich Sebastian hier meldet.
Normaleweise sollte der befehl GetStates und GetAll mehr zurückgeben als nur XC_SUC
Es hat mit älteren gateways funktioniert und man könnte aus dem json mit einem script die zustände auslesen. Habe ich mal gemacht in dem genau dieses XC_SUC am anfang entfernt wurde. Dann könnte der rest als json interpretiert und ausgelesen werden. Bin mir nicht sicher aber ich habe es hier im forum gepostet.
Von auf 09.12.2017 12:15:46 | Gefällt mir (0) | Melden
Das muss spezifisch für das V5 bzw. V5 Plus sein
Wenn ich
http://<ip>/command?XC_FNC=GetStates
beim V4 eingebe bekomme ich ein JSON geliefert scheint also was spezielles für das V5 plus zu sein, da kann ich aber nicht testen da ich es nicht besitze,
Von auf 09.12.2017 12:43:07 | Gefällt mir (0) | Melden
ich jatte das mal vor einigen monaten probiert und meine auch, mehr zurückbekommen zu haben. hatte das dann ruhen lassen.
ist vielleicht ein firmware-bug.
ich werde es dann mal melden
danke erstmal
Von auf 09.12.2017 17:06:52 | Gefällt mir (1) | Melden
ich habe auf einer Synology noch ein NEO-Server laufen und das gibt's ein Logfile. Und siehe da, der fragen den Status des Gateway regelmässig ab ... und der Aufruf steht im NEO Server.log
http://xxx.xxx.xxx.xxx:80/cmd?XC_FNC=getStates&auth=xxxx
und schon bekomme ich ein schönes json-output ... dann werde ich das mal genauer auseinander nehmen.
Von auf 10.12.2017 04:37:37 | Gefällt mir (0) | Melden
Wie sieht denn der Response bzw. JSON exemplarisch aus, ist das gleich zu älteren Gateway Versionen? Dann könnte ich das selber ja auch noch ergänzen. Hast Du irgendeine Möglichkeit gefunden wie das Gateway eine Statusrückmeldung mitteilt? Das wäre ja insbesondere bei Homematic sinnvoll man kann ja schlecht das AIO Gateway sekündlich einen Request schicken nur damit dies einen Status mitteilt. Kann das V5+ eigentlich BidCos?
Von auf 10.12.2017 05:44:17 | Gefällt mir (0) | Melden
Ich komm erst heute nachmittag dazu hier weiter machen, nur das vorab (Auszug)
{"XC_SUC":[
{"type":"HM","adr":"HM-RCV-50.BidCos-RF.BidCoS-RF:1","state":{}},
...
{"type":"HM","adr":"HM-Sen-MDIR-O-2.BidCos-RF.NEQ0320541","state":{"0_aes_key":0,"0_config_pending":false,"0_device_in_bootloader":false,"lowbat":false,"0_rssi_device":-65535,"0_rssi_peer":-65535,"0_sticky_unreach":false,"timeout":false,"0_update_pending":false,"bri":178,"state":"ok"}},
{"type":"HM","adr":"HM-PB-2-FM.BidCos-RF.NEQ0890192:1","state":{"0_aes_key":0,"0_config_pending":false,"0_device_in_bootloader":false,"lowbat":false,"0_rssi_device":-65535,"0_rssi_peer":-65535,"0_sticky_unreach":false,"timeout":false,"0_update_pending":false}},
{"type":"HM","adr":"HmIP-FSM.HmIP-RF.000895699E5C07","state":{"0_config_pending":false,"0_update_pending":false,"0_rssi_device":-79,"0_duty_cycle":false,"timeout":false,"0_rssi_peer":-87,"switchState":"on","ch2State":"on","ch3State":"off","ch4State":"off","meterPower":"125.87","meterVoltage":"227.60","meterEnergyCounter":"28343.30","meterCurrent":"553.00","meterFrequency":"49.97"}},
...
{"type":"TASK","id":1,"active":true},
...
{"type":"INT","adr":"11","state":"00000006"},
{"type":"ONOFF","adr":"12","state":"ON"},
...
]}
Mit einer Statusrückmeldung bin ich noch nicht dran, ggfs muss man da auf UDP setzen, lt. Doku wird ein upd-Paket verschickt, wenn es eine Statusmeldung gibt.
Was mir auf jeden Fall noch fehlt ist das Mapping der 'adresse' zu dem Namen ...
Ich wollte zuerst einmal minütlich abfragen.
Bzgl BidCos: wie kann ich das sicher feststellen? Ich würde ja sagen, weil das auf an vielen Stelle auftaucht.
Von auf 10.12.2017 07:25:28 | Gefällt mir (0) | Melden
Danke für den Auszug. Statusrückmeldungen per UDP kommen im AIO Gateway Modul in IPS an. Du kannst Dir das gerne mit einer Demo von IPS anschauen wenn Dir das bei der Analyse hilft. Wenn Du das Debug Fenster des IO des AIO Gateways bzw. das Debug Fenster des Splitter öffnest, dann siehst Du alles was das AIO Gateway broadcastet. Wie gesagt per Pull abzufragen habe ich bisher nie gemacht, keine Ahnung ob so was ein AIO Gateway aushält, ich finde das aber persönlich keine geeignete Lösung sekündlich einen Request an das AIO Gateway zu schicken, wenn dann muss alles über die Meldungen, die über den Socket kommen auszuwerten sein.
Wie und mit welcher Sprache willst Du denn den Socket aufsetzten?
Da ich keine Homematic Geräte am AIO Gateway angelernt habe, das macht bei mir eine CCU da habe ich kein Gebastel, müsstest Du mal schauen ob über den Socket überhaupt was rein kommt, wenn ein Gerät den Status ändert. Dann könnte ich so was auch noch ergänzen. Eventuell macht das ja Sinn wenn man ein AIO Gateway wirklich als CCU Ersatz betreibt.
Das mit dem JSON ist zwar gut, aber aus meiner Sicht eben nicht geeignet um einen Geräte Status abzubilden, weil man schlecht ständig das AIO Gateway mit Anfragen zuballern kann.
Das Mapping kannst Du ja vornehmen. Die Adresse wird ja übermittelt Du musst dies dann mit Adresse, Data, Type und Seriennummer abgleichen dann kannst Du das Gerät zuweisen. Von wo aus möchtest Du eigentlich senden bzw. den Socket auswerten?
Von auf 10.12.2017 10:56:56 | Gefällt mir (0) | Melden
Mein ersten Ziel ist, das ich für alle HM-Komponenten primär den Batterie-Status und sekundäre die anderen interessanten Stati herausholen möchte und
a) auf einer Web-Seite (natürlich aufgerufen aus der FB) alle Komponenten anzeigen
-> also eine ganz übliche php-Seite auf meinem lokalen Web-Server
b) durch einen zyklische Prüfung eine Meldung (pop-up oder mail) bekomme, wenn eine der Komponenten ein "Problem" hat
-> ein javascript im AM, der den Status feststellt und in einer Variable festhält
-> alle 5 Minuten?
c) auf (b) aufbauen eine zyklische Überprüfung Erzeugung einer Meldung
-> ein javascript im AM, der die o.g. Variable ausliest
-> jede Stunde?
Wobei ich noch nich weis, ob ich diese Meldung überhaupt brauche oder das einfach nur in der FB visualisieren, das es ein problem gibt und dann schaut man via (a) nach, wo das Problem liegt
Eine weitergehende, aber noch nicht ausgegorene Idee ist, das ich den in (b) festgehaltenen Status in der DB speichere, um so mitzubekommen, wie häufig eine bestimmte Situation aufgetreten ist (also zB häufige Timeouts oder wie lange hält wo eine Batterie).
Wie häufig man die Abfrage machen kann ist natürlich eine gute Frage. der NEO-Server, der auf meiner Synology läuft fragt alle 5 Minuten ab.
Bei der Zuordnung der Adresse zu dem Namen im Gerätemanager: die Liste der Geräte und deren Adresse habe ich, das Mapping ist kein Problem, ich hoffe noch auf einen Call, damit ich nicht Tabelle pflegen muss.
Von auf 10.12.2017 11:29:31 | Gefällt mir (0) | Melden
ich habe gerade im NEO Server.log noch etwas gesehen:
Ist ein Fensterkontakt, bei dem ich das Batteriefach geöffnet habe (um ein "error" = "sabotage" zu produzieren).
10/12/2017 15:57:45.603 trace: [x.hub.m.gateway.Handler] from 192.168.178.36 receive STA event:{"type":"HM","adr":"HM-Sec-RHS.BidCos-RF.NEQ1476668","state":{"0_aes_key":0,"0_config_pending":false,"0_lowbat":false,"0_rssi_device":-65535,"0_rssi_peer":-65535,"0_sticky_unreach":false,"timeout":false,"error":"no_error","lowbat":false,"state":"closed"},"_ver":"v5+"}
-> Kappe ab
10/12/2017 15:57:46.063 trace: [x.hub.m.gateway.Handler] from 192.168.178.36 receive STA event:{"type":"HM","adr":"HM-Sec-RHS.BidCos-RF.NEQ1476668","state":{"0_aes_key":0,"0_config_pending":false,"0_lowbat":false,"0_rssi_device":-65535,"0_rssi_peer":-65535,"0_sticky_unreach":false,"timeout":false,"error":"sabotage","lowbat":false,"state":"closed"},"_ver":"v5+"}
-> Kappe wieder drauf
10/12/2017 15:57:48.485 trace: [x.hub.m.gateway.Handler] from 192.168.178.36 receive STA event:{"type":"HM","adr":"HM-Sec-RHS.BidCos-RF.NEQ1476668","state":{"0_aes_key":0,"0_config_pending":false,"0_lowbat":false,"0_rssi_device":-65535,"0_rssi_peer":-65535,"0_sticky_unreach":false,"timeout":false,"error":"no_error","lowbat":false,"state":"closed"},"_ver":"v5+"}
also gibt es Events bei Änderungen ...
Ich habe aber dabei eine Fehler festgestellt:
ich habe auf dem NEO-Server (Version 2.2.0 und auch 2.2.1) ein Task habe, der bei einem Fensterkontakt auf "sabotage" prüft, löst der nicht aus, im Gegensatz zu dem gleichen Task auf dem Gateway V5+. Passiert auch, wenn ich auf "state" = "closed" prüfe.
Von auf 10.12.2017 13:27:25 | Gefällt mir (0) | Melden
kannst du diesen befehl testen
http://ip/command?XC_FNC=setVar&id=10&type=ONOFF&value=ON&auth=xxxxx
natürlich mit einer deiner boolean variablen
Von auf 10.12.2017 13:39:18 | Gefällt mir (0) | Melden
jein.
das geht
xxx.xxx.xxx.xxx:8088/cmd?XC_FNC=setVar&id=02&type=ONOFF&value=ON&auth=xxxx
/command?XC_FCN ... nicht
Von auf 10.12.2017 13:47:06 | Gefällt mir (0) | Melden
ok danke
Von auf 10.12.2017 15:12:42 | Gefällt mir (0) | Melden
Also falls das jemand mal mit einem V5 Plus testen kann würde mich das brennend interessieren ob da was über den Multicast Socket rein kommt wenn das Gerät geschaltet wird und den Status ändert. Bei V4 kommt da was rein wenn über die CCU was geschaltet wird.
Von auf 10.12.2017 16:09:50 | Gefällt mir (0) | Melden
kann ich gelegentlich machen..
hast du ein code-fragment, auf das ich aufsetzen kann? auf der synology habe ich keinen c-compiler, also wäre php am besten oder javascript in der node.js-umgebung.
sonst müsste ich mich da rein lesen (dann dauert es etwas)
Von auf 10.12.2017 16:24:49 | Gefällt mir (0) | Melden
Das einfachste wäre Du installierst Dir eine IPS Demo in einem Docker auf der Synology das AIO Gateway Modul erstellt Dir den Socket automatisch und dann kannst Du auch alles im Debug Fenster einsehen und Aufzeichen bzw. als Text exportieren. Dann musst Du Dich nicht extra einlesen wegen dem Socket, wie Du das dann final mit dem Socket selbst lösen willst kannst Du Dich ja selber später immer noch festlegen.
Ich werde das auch mal ergänzen, IPS nutzt ja auch PHP. Egal wer was fertig hat kann man dann den Code ja 1:1 übernehmen Du meinen oder ich Deinen.
Von auf 10.12.2017 17:31:18 | Gefällt mir (0) | Melden
Meine Synology hat leider kein Docker - gerade etwas zu alt dafür ... schaun wir mal.
Wenn ich das auf die Schnelle richtig gesehen habe, gibt's das auch für MacOS und Win. mal schauen, ob's klappt
Von auf 10.12.2017 17:40:57 | Gefällt mir (0) | Melden
Ja gibt es auch für Win und MacOS, das ist wohl erst mal das einfachste, ist ja nur um die Rückmeldung über den UDP Socket sauber mitlesen und aufzeichnen zu können.
Von auf 10.12.2017 17:45:40 | Gefällt mir (0) | Melden
ok, ich habe die managment-console offen, aber noch ist mir nicht klar, wie ich da module hinzufüge
Von auf 10.12.2017 18:33:46 | Gefällt mir (0) | Melden
Unter Kern Instanzen auf Modules doppelklick dann auf Hinzufügen dort
https://github.com/Wolbolar/IPSymconAIOGateway
eingeben und mit Ok bestätigen. Dann unter Splitter Instanzen rechts Klick und Instanz hinzufügen und dort AIO gateway auswählen. Um das um besten zu analysieren legst Du als IO einen Multicast Socket an und wählst dann im Splitter den Multicast IO als Übergeordnete Instanz.
Den Multicast IO legst Du unter IO Instanzen an Rechts Klick neue Instanz hinzufügen _> Multicast Socket
Als Werte trägst Du im Multicast Socket ein
Sende Host IP des Rechners
Sende-Port 1901
Empf.-Host IP des Rechners
Empf-Port: 1901
Multicast 224.0.0.1
Aktiviere Broadcast false
Aktiviere Reuse Address true
Aktiviere Loopback false
Wenn Du dann auf Übernhmen gehst und der Socket aktiv ist kannst Du den grünen Käfer Debug anklicken dann siehst Du die Daten die vom AIO Gateway reinkommen.
Von auf 11.12.2017 03:38:53 | Gefällt mir (0) | Melden
sind nach schnellem Blick die gleichen Events, die ich auch im NEO Server.log gesehen habe
TXT: 11.12.2017 07:56:34.00 | RECEIVED | GET<LF>
TXT: 11.12.2017 07:56:34.00 | RECEIVED | DHCP:FALSE<LF>HWV:A1<LF>VER:2.2.1<LF>VID:FFFF<LF>NAME:HomeServer<LF>IP:192.168.178.91<LF>PT:8088<LF>SN:255.255.255.0<LF>GW:0.0.0.0<LF>DNS:192.168.178.1<LF>MAC:00-11-32-36-af-a7<LF>
TXT: 11.12.2017 07:56:34.00 | RECEIVED | DHCP:FALSE<LF>HWV:A1<LF>VER:2.2.1<LF>VID:FFFF<LF>NAME:HomeServer<LF>IP:192.168.178.91<LF>PT:8088<LF>SN:255.255.255.0<LF>GW:0.0.0.0<LF>DNS:192.168.178.1<LF>MAC:00-11-32-36-af-a7<LF>
TXT: 11.12.2017 07:56:34.00 | RECEIVED | DHCP:FALSE<LF>HWV:EA<LF>VER:1.0.18<LF>VID:FFFF<LF>NAME:Zuhause<LF>IP:192.168.178.36<LF>PT:80<LF>SN:255.255.255.0<LF>GW:192.168.178.1<LF>DNS:192.168.178.1<LF>MAC:40-66-7A-00-41-C2<LF>TMP_ID:436de85c<LF>
TXT: 11.12.2017 07:56:36.00 | RECEIVED | STA:{"type":"HM","adr":"HM-CC-RT-DN.BidCos-RF.NEQ1773725","state":{"0_aes_key":0,"0_config_pending":false,"0_device_in_bootloader":false,"0_inhibit":false,"0_lowbat":false,"0_rssi_device":-65535,"0_rssi_peer":-55,"0_sticky_unreach":false,"0_unreach":false,"0_update_pending":false,"mode":"manu","error":"no_error","batLvl":2.9,"valveLvl":99,"boostTime":0,"act_temp":23.5,"state":24},"_ver":"v5+"}<CR><LF>
...
: 11.12.2017 07:57:16.00 | RECEIVED | STA:{"type":"HM","adr":"HM-WDS10-TH-O.BidCos-RF.OEQ0087723","state":{"0_config_pending":false,"lowbat":false,"0_rssi_device":-65535,"0_rssi_peer":-60,"0_sticky_unreach":false,"timeout":false,"temp":6.6,"hum":84},"_ver":"v5+"}<CR><LF>
TXT: 11.12.2017 07:57:16.00 | RECEIVED | STA:{"type":"HM","adr":"HM-WDS10-TH-O.BidCos-RF.OEQ0087723","state":{"0_config_pending":false,"lowbat":false,"0_rssi_device":-65535,"0_rssi_peer":-60,"0_sticky_unreach":false,"timeout":false,"temp":6.6,"hum":84},"_ver":"v5+"}<CR><LF>
...
TXT: 11.12.2017 07:57:39.00 | RECEIVED | STA:{"type":"HM","adr":"HM-CC-RT-DN.BidCos-RF.NEQ1772641","state":{"0_aes_key":0,"0_config_pending":false,"0_device_in_bootloader":false,"0_inhibit":false,"0_lowbat":false,"0_rssi_device":-65535,"0_rssi_peer":-65535,"0_sticky_unreach":false,"0_unreach":false,"0_update_pending":false,"mode":"auto","error":"no_error","batLvl":2.9,"valveLvl":30,"boostTime":0,"act_temp":23.3,"state":21},"_ver":"v5+"}<CR><LF>
TXT: 11.12.2017 07:57:39.00 | RECEIVED | STA:{"type":"HM","adr":"HM-CC-RT-DN.BidCos-RF.NEQ1772641","state":{"0_aes_key":0,"0_config_pending":false,"0_device_in_bootloader":false,"0_inhibit":false,"0_lowbat":false,"0_rssi_device":-65535,"0_rssi_peer":-65535,"0_sticky_unreach":false,"0_unreach":false,"0_update_pending":false,"mode":"auto","error":"no_error","batLvl":2.9,"valveLvl":30,"boostTime":0,"act_temp":23.3,"state":21},"_ver":"v5+"}<CR><LF>
TXT: 11.12.2017 07:57:40.00 | RECEIVED | STA:{"type":"HM","adr":"HM-Sec-SCo.BidCos-RF.OEQ0199944","state":{"0_aes_key":0,"0_config_pending":false,"0_device_in_bootloader":false,"0_lowbat":false,"0_rssi_device":-65535,"0_rssi_peer":-65535,"0_sticky_unreach":false,"timeout":false,"0_update_pending":false,"error":"no_error","lowbat":false,"state":"closed"},"_ver":"v5+"}<CR><LF>
TXT: 11.12.2017 07:57:40.00 | RECEIVED | STA:{"type":"HM","adr":"HM-Sec-SCo.BidCos-RF.OEQ0199944","state":{"0_aes_key":0,"0_config_pending":false,"0_device_in_bootloader":false,"0_lowbat":false,"0_rssi_device":-65535,"0_rssi_peer":-65535,"0_sticky_unreach":false,"timeout":false,"0_update_pending":false,"error":"no_error","lowbat":false,"state":"closed"},"_ver":"v5+"}<CR><LF>
TXT: 11.12.2017 07:57:40.00 | RECEIVED | STA:{"type":"HM","adr":"HM-Sec-SCo.BidCos-RF.OEQ0199944","state":{"0_aes_key":0,"0_config_pending":false,"0_device_in_bootloader":false,"0_lowbat":false,"0_rssi_device":-65535,"0_rssi_peer":-65535,"0_sticky_unreach":false,"timeout":false,"0_update_pending":false,"error":"no_error","lowbat":false,"state":"closed"},"_ver":"v5+"}<CR><LF>
Von auf 11.12.2017 03:53:32 | Gefällt mir (0) | Melden
Und was passiert wenn Du ein Homematic Gerät schaltest? Kommst dann auch eine Message über den Socket? Dann müsste man ja nicht pullen. Dann würde es reichen ein mal in der Stunde oder eben mit einem Intervall der Wahl den Status aller Geräte auszulesen und z.B. den Zustand der Batterie in einer Variable abzulegen.
Von auf 11.12.2017 05:51:54 | Gefällt mir (0) | Melden
Bezüglich BidCos kannst ja mal schauen ob ein V5 Plus ein gleichwertiger Ersatz zu einer CCU ist. Sollte BidCos vollständig auf einem V5 Plus wie auf einer CCU implementiert sein sollte sich ein V5 Plus dann genauso wie eine CCU ansprechen lassen. Das kannst Du prüfen ob Du irgendeine Antwort bekommst wenn Du einen Homematic Konfigurator öffnest und dort mal die IP des V5 Plus eingibst. Sollte da irgendeine Antwort kommen wäre das zumindest für Homematic die einfachste Lösung von EQ3 ist BidCos und alle Datenpunkte sauber dokumentiert.
Neuen Kommentar hinzufügen 
Dez 26, 2017 - 15:59
var dgram = require('dgram');
var client = dgram.createSocket( { type: 'udp4', reuseAddr: true } );
client.on('listening', function () {
var address = client.address();
console.log('UDP Client listening on ' + address.address + ":" + address.port);
client.setBroadcast(true);
});
client.on('message', function (message, remote) {
var data = message.toString();
var jdata, event;
if (data.length > 4 && data.substr(0,4) == "STA:") {
event = data.substr(0,3);
jdata = JSON.parse(data.substr(4));
}
if (jdata)
console.log('from: ' + remote.address + ':' + remote.port + ' - event=' + event + ', data=', jdata);
else
console.log('from: ' + remote.address + ':' + remote.port + ' - ' + message);
});
client.bind(1901);die STA-Events sind die jeweiligen Status-Änderungen der Komponenten - ob nur Homematic oder auch andere kann ich nicht sagen, weil die anderen Komponenten die ich habe, keinen Status melden.
Neuen Kommentar hinzufügen
Von
Ich habe mich heute morgen für die neue API angemeldet. Kam eine Mail zurück, das die sich bei mir melden - Zielgruppe scheint aber eher kommerzielle Anwender zu sein. Warten wir ab ...
Neuen Kommentar hinzufügen