Hallo,
ich habe mich ans Werk gemacht und mein erstes Modul geschrieben.
Mit diesem Modul kann man alle Aktoren / Sensoren / Timer und Informationen vom xs1 der Firma EZcontrol auslesen.
Sämtliche Daten werden in Readings eingelesen. Somit kann man seine xs1 im FHEM für den Empfang nutzen.
Derzeit werden Daten nur empfangen.
Ein Gedanke ist, das ganze ggf weiter zu bringen, das man auch die xs1 steuern kann.
MfG
... hier mal eine Neuerung schon.
Das Modul wurde umbenannnt weil ein 2. welches mit diesem zusammen arbeitet hinzukommt.
Hallo,
Guten Abend, ich hätte da eine Anfängerfrage ;-)
Ist es derzeit schon möglich ein xs1 mit Passwordschutz anzubinden?
Wenn ja wie geht das?
Ich wäre ebenfalls sehr interessiert an einer möglichkeit das xs1 auch über FHEM steuern zu können. Dies ist ja recht einfach über http Befehle möglich. Wenn Sie interesse hätten könnte ihnen eine inoffizielle xs1 http dokumentation zukommen lassen.
Vielen Dank
Guten Abend,
ich werde es mal testen.
Du kannst auf jedenfall ohne Passwort, dies auslesen mit der xs1Bridge. Ich bin soeben in der Umsetzung das auch Schalter angelegt werden unsw.
Welche Firmware nutzt du?
MfG
Aktuell setze ich Version 4.0.0.5326 ein
Das ist auch die Version welche ich nutze.
Da ich gerade nicht meine xs1 umkonfigurieren kann mache mal bitte folgenden Test.
Nutze mal diesen http Befehl
Zitathttp://<IP-von-DIR>/control?callback=cname&cmd=get_list_sensors
und schaue was passiert.
Ich habe glaube dunkel in Erinnerung das das mit einem Passwort nicht funktioniert.
Genau an dieser Stelle blieb der Hersteller "stehen".
Also ohne PW geht dies auf jedenfall.
MfG
EDIT: Du kannst gern auch mal dies nach dem Schema probieren. http://username:password@www.deinedomain.tld/
Hallo,
ich habe jetzt auch mal ein paar Experimente gemacht, jedoch werde im in allen fällen immer zuerst nach username und passwort gefragt, egal welche URL Konstellation ich benütze. Hier meine bisherige Auflistung welches nicht geklappt hat:
http://192.168.178.242/control?callback=cname&cmd=get_list_sensors
http://admin:MEINPASSWORT@192.168.178.242/control?callback=cname&cmd=get_list_sensors
http://192.168.178.242/control?user=Administrator&pwd=MEINPASSWORT&callback=cname&cmd=get_list_sensors // Inoffizielle xs1 Dokumentation
http://192.168.178.242/control?user=admin&pwd=MEINPASSWORT&callback=cname&cmd=get_list_sensors
http://Administrator:MEINPASSWORT@192.168.178.242/control?callback=cname&cmd=get_list_sensors
Es scheitert hier anscheinend tatsächlich an der Basic access authentication.
MfG
Hallo,
dann wird dir leider nichts anderes übrig bleiben vielleicht FHEM als Oberfläche von der Ferne freizugeben und die xs1 nur intern ohne Freigabe nach außen einzurichten wo du keine Passwortabfrage erhält.
Das werden wir nicht gelöst bekommen, da wir da in die Firmware von xs1 eingreifen müssten. Da diese nicht erhältlich ist und nicht weiterentwickelt wird, so kannst du ggf nur dies mit dem Workaround nutzen. Daten vom xs1 in FHEM umsetzen ist machbar.
Derzeit kannst du mit dem Modul alles auslesen und vorerst als Reading weiter verarbeiten.
Eine Entwicklung zumsteuern ist in der Mache.
MfG
Moin HomeAuto_User,
vielen Dank für das Modul.
Wäre es möglich bei den Readings statt der id Nummern die Namen auszulesen? so braucht man immer erst einen Übersetzer, zumal die fortlaufende Nummerierung und id Nr nicht identisch sind.
Ciao
Siggi
Hallo Siggi,
Zitat von: meergeist am 05 Februar 2018, 16:23:36
Wäre es möglich bei den Readings statt der id Nummern die Namen auszulesen? ...
Das ist möglich. Ich habe das ganze schon im Test bei mir laufen und muss nur noch einen Fehler abfangen. Gib mir bitte noch ein paar Tage und ich lade es hoch.
In der neuen Version wird es dann wie folgt aussehen:
Readings:
Aktor_08 | Value
Aktor_08_Name | Name (welcher von Dir im XS1 defineirt wurde)
...
Zitat von: meergeist am 05 Februar 2018, 16:23:36
... zumal die fortlaufende Nummerierung und id Nr nicht identisch sind.
Dem kann ich nicht ganz folgen. Das Gerät hat feste Positionen welche als Aktor_ID wiedergegeben werden. So sollte es auch bisher sein. (bei mir ist es auf jedenfall bisher so. Aktor_ID 17 = Aktor ID 17 im Gerät) Ist es machbar, das du mir dies mal näher erläutern kannst.
Alternativ, mir die Daten von den Aktoren (http://IP/control?callback=cname&cmd=get_list_actuators) ausgeben und daran erläutern wo welche ID´s verschoben sind.
Natürlich sollte es keine Differenzen in der Nummerierung geben und wir finden den Fehler ;-)
Welche Firmware nutzt du im xs1?
MfG Marco
Moin Marco,
meine firmware 3.0.0.4493.
Die Differenz in der Nummerierung bezieht sich nicht auf dein Modul, sondern die Durchnummerierung Aktor 1...64
auf dem XS1 Webinterface ist nicht identisch mit den ausgelesenen "ID" Nummern, deswegen elende sucherei.
Kann sein das das in der 4er Fw nicht mehr der Fall ist, die brachte mir aber wenige Stunden nach update einen Absturz,
bin deswegen bei der 3.0.0.4493 geblieben.
Schön wären auch Begrenzungsmöglichkeiten für die Events.
Vielen Dank für das Update.
Ciao
Siggi
Zitat von: meergeist am 05 Februar 2018, 17:51:41
Die Differenz in der Nummerierung bezieht sich nicht auf dein Modul, sondern die Durchnummerierung Aktor 1...64
auf dem XS1 Webinterface ist nicht identisch mit den ausgelesenen "ID" Nummern, deswegen elende sucherei.
Kann sein das das in der 4er Fw nicht mehr der Fall ist, die brachte mir aber wenige Stunden nach update einen Absturz,
bin deswegen bei der 3.0.0.4493 geblieben.
Bei mir sind die Zuordnungen eindeutig. ID 1 in FHEM = ID 1 im xs1 Web = ID 1 xs1 Config
Zitat von: meergeist am 05 Februar 2018, 17:51:41
Schön wären auch Begrenzungsmöglichkeiten für die Events.
Was meinst du damit? Möchtest du bei einem Event, also eine Wertänderung verarbeiten? ---> Das Bsp. ist in Entwicklung und da kannst du sogar die xs1 von FHEM schalten ;) (Dafür kommt aber ein neues Modul) Das ganze harmoniert dann zusammen. Aufgrund der vielen Möglichkeiten ist es nur sehr vielseitig.
DENNOCH gut zu wissen, das du mit der FW 3 ebenso zum "testen" bereitstehen würdest. 8)
Moin Marco,
die Zuordnung der id Nr ist bei mir auch eindeutig.
Ich versuchs nochmal:
In der XS1 Confg kann man die Reihenfolge der Aktoren/Sensoren mit der Funktion "verschieben" ändern, die "ID" Nr. bleibt dabei aber erhalten.
Wenn ich einen einzelnen Aktor auslese erhalte ich als Antwort: "actuator": {"number": 1, "name": "Rol_Kue",.....
"number 1" ist hierbei der 1.Aktor auf der XS1 Confg Seite, die "id" Nr erscheint hier garnicht.
Wenn ich alle Aktoren gleichzeitig auslese erhalte ich als Antwort: "actuator": [{"name": "Rol_Kue","id": 14,..
"number" erscheint hier nicht.
Man sieht hier das "Rol_Kue" vom ursprünglichen Platz 14 auf Platz 1 der XS1 Confg Liste verschoben wurde.
Wenn in der nächsten Version in den Readings die Namen erscheinen ist doch alles bestens.
Ciao
Siggi
Guten Morgen Siggi,
Ich habe nun verstanden was du meinst. Diesen Fall schaue ich mir an. Danke für den Hinweis. Vielleicht kann man da eine Lösung finden.
Das Update ist eingecheckt. Du kannst nun mit viewDevice_name als Attribut die Orginal Namen vom Gerät auslesen. So erhältst du jeweils 2 Readings pro Aktor / Sensor. (_ID und _name)
MfG
Moin,
nach dem Update funktioniert das Modul leider garnicht mehr, es finden keine updats der Readings mehr statt, und es gibt keine Events mehr.
Hab das Modul gelöscht und neu definiert, es bleibt im initialisierungs Modus stehen. Im Log keine Meldungen.
Ciao
Siggi
Hallo Siggi, sobald ich Heim bin werde ich versuchen den Fall zu rekonstruieren.
Schalte mal innerhalb des Modules die Debug=1 Option an. So siehst du mehr Erkenntnisse Ggf zeige diesen Auszug mal bitte. (Achtung es sind erhebliche Ausgaben)
Das sollte die Erkenntnis zeigen, wieso es kein Update durchführen kann.
Mfg
Moin,
inzwischen ist der Modus active und jede Menge Meldungen im Logfile:
------------- ERROR CHECK - START -------------
2018.02.06 15:40:58 1: DEBUG> xs1Bridge: GetUpDate | RemoveInternalTimer + InternalTimer
2018.02.06 15:40:58 1: DEBUG> xs1Bridge: GetUpDate ERROR | Modul xs1Dev not existent! Please check it to be available!
2018.02.06 15:40:58 1: DEBUG> xs1Bridge: GetUpDate | Adresse: http://xxx.xxx.x.xx/control?callback=cname&cmd=get_list_actuators
2018.02.06 15:40:58 1: DEBUG> xs1Bridge: GetUpDate | Adresse HTTP request Code: 200
2018.02.06 15:40:59 1: DEBUG> xs1Bridge: Aktor_14 | shutter | Rol_Kue | 100 | F1 off | F2 on | F3 on_wait_off | F4 on_wait_off
2018.02.06.............................................
Was beddeutet das?
Die Readings werden nicht upgedatet.
Ciao
Siggi
Hallo,
ZitatMoin,
inzwischen ist der Modus active und jede Menge Meldungen im Logfile:
das ist normal bei aktivem Debug (Debug=1). Das ist ein sehr ausführlicher Modus um Fehler besser zu lokalisieren.
Zitat2018.02.06 15:40:58 1: DEBUG> xs1Bridge: GetUpDate ERROR | Modul xs1Dev not existent! Please check it to be available!
Das ist eine Überprüfung zur Weiterverarbeitung, das Modul xs1Dev existiert nicht, da es soeben entwickelt wird. Dies ist irrelevant zum derzeitigem Nutzen.
Zitat2018.02.06 15:40:58 1: DEBUG> xs1Bridge: GetUpDate | Adresse: http://xxx.xxx.x.xx/control?callback=cname&cmd=get_list_actuators
2018.02.06 15:40:58 1: DEBUG> xs1Bridge: GetUpDate | Adresse HTTP request Code: 200
2018.02.06 15:40:59 1: DEBUG> xs1Bridge: Aktor_14 | shutter | Rol_Kue | 100 | F1 off | F2 on | F3 on_wait_off | F4 on_wait_off
Besagt aus, das das Kommando an das xs1 gesendet werden kann (Adresse: http://....) und du auch eine Antwort 200 von der HTTP Abfrage zurück erhällst.
HTTP-Code 200 bedeutet
Die Anfrage wurde erfolgreich bearbeitet und das Ergebnis der Anfrage wird in der Antwort übertragen. | OK Ich entnehme der Zeile
Zitat2018.02.06 15:40:59 1: DEBUG> xs1Bridge: Aktor_14 | shutter | Rol_Kue | 100 | F1 off | F2 on | F3 on_wait_off | F4 on_wait_off
das die Verbindung und auch das auslesen des Aktor_14 klappte.
Nun muss nur der Grund gefunden werden, wieso die Readings nicht aktualisiert werden.
Auf welchen Intervall hast du derzeit das Ganze eingestellt? Option, Intervall= ??
Hast du weitere Optionen vielleicht aktiv?
EDIT: Sollte bei dir der Status "Initialized" nach dem define stehen bleiben, so starte bitte FHEM neu. Soeben hatte ich auch diese Erscheinung, Neustart und es klappte wieder. *arbeite dran*
Moin Marco,
die Readings werden jetzt aktualisiert, aber man kann dies nicht im geöffneten Fenster sehen (in rot).
(ich bin mir jetzt nicht ganz sicher aber die Aktualisierung fand zu Anfang nicht statt)
Im Eventmonitor keine Events. In den DOIFS funktioniert die Abfrage, aber es wird nicht getriggert.
Im Sensorlog seit dem Update keine Einträge mehr.
Intervall = 60
Was kann ich tun?
Ciao
Siggi
Hallo Siggi,
Zitat von: meergeist am 06 Februar 2018, 18:59:32
... aber man kann dies nicht im geöffneten Fenster sehen (in rot).
... Im Eventmonitor keine Events. In den DOIFS funktioniert die Abfrage, aber es wird nicht getriggert.
Nutze die Version welche ich dir hier angepinnt habe. Ich habe das zwischenzeitlich mal geändert weil ich dies für die Weiterentwicklung als doppelt fand.
Ich werde dies nun drin lassen und aktualisieren.
Zitat von: meergeist am 06 Februar 2018, 18:59:32
Im Sensorlog seit dem Update keine Einträge mehr.
Hast du dir selber ein Log angelegt? Von Haus aus wird bisher kein Log angelegt von den Sensoren.
Dies passiert bisher nur in der Entwicklerversion des anderen Modules woran ich arbeite. Da werden die Sensoren dann automatisch angelegt und auch Logfile.
Das ganze kann aber noch nicht freigegeben werden, da dort noch viele Dinge intergriert werden müssen.
Moin Marco,
vielen Dank für die schnelle Hilfe, mir der Version läuft scheinbar wieder alles, werds morgen mal weiter testen.
Das Sensolog hatte ich selbst angelegt und in das entsprechende Plott eingebunden, hat auch gut funktioniert und ein
HTTPMOD Device eingespart...
Ciao
Siggi
Hallo,
zunächst mal Danke ! für deine Entwicklung ich habe die xs1 schon seit Jahren nur noch im Regal liegen.
Mir fehlte die Anbindung an FHEM.
Jetzt kann ich sie wieder einsetzen um Wettersensoren die ich sonst irgendwie nicht empfangen konnte in FHEM zu integrieren.
Leider habe ich jetzt 2 Probleme:
Im FHEM-Logfile steht folgendes:
2018.03.13 12:24:52.232 1: PERL WARNING: Use of uninitialized value $_ in split at ./FHEM/88_xs1Dev.pm line 164.
2018.03.13 12:24:52.233 1: PERL WARNING: Use of uninitialized value $cmdList in string ne at ./FHEM/88_xs1Dev.pm line 165.
2018.03.13 12:24:52.233 1: PERL WARNING: Use of uninitialized value $cmdList in concatenation (.) or string at ./FHEM/88_xs1Dev.pm line 165.
2018.03.13 12:24:52.233 1: PERL WARNING: Use of uninitialized value $cmdList in string eq at ./FHEM/88_xs1Dev.pm line 166.
2018.03.13 12:24:52.235 1: PERL WARNING: Use of uninitialized value $cmdList in string ne at ./FHEM/88_xs1Dev.pm line 177.
2018.03.13 12:24:52.235 2: xs1Dev_Sensor_01: Device windspeed are not supported for Dispatch
2018.03.13 12:24:52.238 2: xs1Dev_Sensor_02: Device winddirection are not supported for Dispatch
2018.03.13 12:24:52.241 2: xs1Dev_Sensor_03: Device windvariance are not supported for Dispatch
2018.03.13 12:24:52.250 2: xs1Dev_Sensor_13: Device waterdetector are not supported for Dispatch
2018.03.13 12:24:52.253 2: xs1Dev_Sensor_14: Device waterdetector are not supported for Dispatch
2018.03.13 12:24:52.256 2: xs1Dev_Sensor_15: Device waterdetector are not supported for Dispatch
2018.03.13 12:24:52.259 2: xs1Dev_Sensor_16: Device other are not supported for Dispatch
2018.03.13 12:24:52.262 2: xs1Dev_Sensor_17: Device counter are not supported for Dispatch
2018.03.13 12:24:52.265 2: xs1Dev_Sensor_18: Device counterdiff are not supported for Dispatch
2018.03.13 12:24:52.276 2: xs1Dev_Sensor_28: Device rain_1h are not supported for Dispatch
2018.03.13 12:24:52.279 2: xs1Dev_Sensor_29: Device rain_24h are not supported for Dispatch
2018.03.13 12:24:52.291 2: xs1Dev_Sensor_38: Device barometer are not supported for Dispatch
2018.03.13 12:24:52.294 2: xs1Dev_Sensor_39: Device uv_index are not supported for Dispatch
2018.03.13 12:24:52.297 2: xs1Dev_Sensor_40: Device light are not supported for Dispatch
2018.03.13 12:24:52.300 2: xs1Dev_Sensor_41: Device windspeed are not supported for Dispatch
2018.03.13 12:24:52.303 2: xs1Dev_Sensor_42: Device winddirection are not supported for Dispatch
2018.03.13 12:24:52.306 2: xs1Dev_Sensor_43: Device rainintensity are not supported for Dispatch
2018.03.13 12:24:52.309 2: xs1Dev_Sensor_44: Device rain are not supported for Dispatch
Die Temp und Feuchte Sensoren gehen, aber Wind, Luftdruck, Regen usw. liefern keine Werte.
Was muss ich hier machen?
Und apptime max liefert folgendes:
name function max count total average maxDly avgDly TS Max call param Max call
tmr-xs1Bridge_GetUpDate HASH(0x4f25f78) 12606 7 82875.93 11839.42 63.86 11.03 13.03. 12:09:12 HASH(xs1)
Ist die Laufzeit bei euch auch so lang?
Mein FHEM läuft auf einem Raspberry PI 3
Schon mal Vielen Dank,
Markus
Hallo,
ich wollte vorerst noch kurz mich zu Wort melden.
Es gibt ein Update für die Bridge wo eine Blacklist eingearbeitet wurde.
Zitat....are not supported for Dispatch
Solche Meldungen erscheinen wenn der Typ noch nicht eingearbeit wurde in das Programm.
Bitte in dem Falle, mir per PN die komplette Ausgabe der Daten vom http Befehl get_list_actors zukommen lassen, damit ich dies testen und generieren kann zum einarbeiten.
Für einige Tage werde ich die Arbeit ruhen lassen, da ich in die wohlverdiente Alltagesauszeit ;-) fliege.
Dann gehts weiter.
MfG
Werde das auch demnächst intenver testen. Im Moment überrascht mich FHEM aber ständig noch mit der Meldung:
FileLog_xs1Bridge already defined, delete it first
selbst wenn ich alles, was es an FileLogs zum xs1 gibt, vorher gelöscht habe. Erstt dachte ich, selber einen Fehler zu machen - was ich nach wie vor keinesfalls ausschließe - aber wie gesagt kommt diese Meldung jedes Mal.
Zitat von: duke-f am 28 März 2018, 16:25:55
Werde das auch demnächst intenver testen. Im Moment überrascht mich FHEM aber ständig noch mit der Meldung:
FileLog_xs1Bridge already defined, delete it first
selbst wenn ich alles, was es an FileLogs zum xs1 gibt, vorher gelöscht habe. Erstt dachte ich, selber einen Fehler zu machen - was ich nach wie vor keinesfalls ausschließe - aber wie gesagt kommt diese Meldung jedes Mal.
Hallo,
hast du das aktuelle modul geupdatet?
MfG
Aus dem regulären Update? Ja, aber ich kann es gerne wiederholen.
Zitat von: duke-f am 01 April 2018, 15:06:51
Aus dem regulären Update? Ja, aber ich kann es gerne wiederholen.
Welche Version nutzt du von dem Modul und wann genau tauchst diese Meldung auf?
Ich habe bei mir das Ganze nachgestellt und ich erhalte maximal die Information beim Neustart von FHEM da der LogLevel der Nachricht auf 3 gestellt ist.
Im nächsten Update wird dieser auf 4 *hochgeschraubt*.
Ja, ist bei mir wahrscheinlich auch so, dass das beim Neustart auftritt. Ich starte derzeit öfters, da ich auch an anderen Schrauben drehe. Aber auch dann sollte es und auch nicht bei höherem Loglevel auftreten, denke ich. Kann natürlich mal ein Workaround sein.
Bin allerdings auch froh um das Modul. Ich habe einige Steckdosen, die mal mit den CULs nicht zuverlässig schalten. Das XS1 ist da deutlich sicherer. Bisher gehe ich eben notfalls den Umweg, jetzt könnte ich das deutlich besser integrieren.
Zitat von: duke-f am 01 April 2018, 18:10:12
Kann natürlich mal ein Workaround sein. ...
Ich habe es zur Kontrolle als Ausgabe eingebunden. Man kann natürlich dies herausnehmen zum Schluss, da stimme ich Dir zu.
Gibt es bei dir Sensoren welche bisher nich erkannt werden oder immer im Zustand Defined bleiben? Eine weitere Integration von div. Sensoren vervollständige ich soeben.
Musst Du mir einige Tage Zeit geben, dann gehe ich mal alle nacheinander durch. Jetzt sind etwas Familienverpflichtungen im Vordergrund - nein, nicht leider ;)
Hmmm, irgendwas mache ich da wohl noch falsch. Sobald ich das Attribut xs1_control auf 1 setze, füllt sich meine Config kontinuierlich weiter mit Einträgen (jeweils 64 für die Aktoren und anschließend 64 für die Sensoren, da ich keine Blacklist habe):
xs1Dev: Unknown device xs1Dev_Aktor_01 01 A IODev=XS1_bridge, please define it
War wohl doch nichts, so auf die Schnelle mal aktivieren und sehen, was passiert....
Zitat von: duke-f am 04 April 2018, 11:12:17
xs1Dev: Unknown device xs1Dev_Aktor_01 01 A IODev=XS1_bridge, please define it
Hallo,
Diese Meldung sollte erscheinen wenn du Aktoren in der XS1 definiert hast und diese noch nicht in FHEM angelegt sind.
Okay, dann habe ich das wirklich komplett falsch verstanden. Ich dachte, dass die wie beispielsweise bei ESPEasy sei, da werden die angeschlossenen Devices automatisch in FHEM angelegt.
Moin Marco,
hoffe du hattest schöne Urlaubstage.
Läuft soweit alles prima, Habe leider noch Probleme mit den Blacklisten, die
Anzahl der unterdrückten Devices stimmt zwar aber die Nummern sind nur zum Teil die Richtigen, die meisten aber sind völlig andere als in der Liste angegeben.
Was mach ich da falsch?
Ps. wäre es nicht sinnvoll die beiden Threads zusammenzuführen?
Ciao
Siggi
Hallo Siggi,
danke der Nachfrage.
Zitat von: meergeist am 05 April 2018, 15:25:40
Moin Marco,
hoffe du hattest schöne Urlaubstage.
Läuft soweit alles prima, Habe leider noch Probleme mit den Blacklisten, die
Anzahl der unterdrückten Devices stimmt zwar aber die Nummern sind nur zum Teil die Richtigen, die meisten aber sind völlig andere als in der Liste angegeben.
Was mach ich da falsch?
Ps. wäre es nicht sinnvoll die beiden Threads zusammenzuführen?
Ciao
Siggi
Ab sofort werden wir den Faden HIER (https://forum.fhem.de/index.php/topic,85137.0.html)gesammelt fortführen.
Was dein Problem mit den unterdrückten Devices angeht, so wäre es schön, mir dies mal zu veranschaulichen. Bisher kann ich mir nichts darunter vorstellen wie du dies meinst.
MfG
Moin Marco,
ganz einfach auf die auf die schwarze Sensorliste gesetzt: 1,2,5,6,7,8,9,10
verschwunden sind 1,2,6,8,
5,7,9,10 sind noch da, düfür sind aber andere verschwunden, welche ? hab ich noch nicht rausgesucht
Ciao
Siggi
Hallo,
Zitat von: meergeist am 05 April 2018, 19:05:54
Moin Marco,
ganz einfach auf die auf die schwarze Sensorliste gesetzt: 1,2,5,6,7,8,9,10
verschwunden sind 1,2,6,8,
5,7,9,10 sind noch da, düfür sind aber andere verschwunden, welche ? hab ich noch nicht rausgesucht
Ciao
Siggi
Ja ich habe es nachvollzogen.
Es liegt ganz einfach daran, das du die ID vertauscht hast in der xs1 im laufe der Zeit ;D ;)
Eine mögliche Lösung wird erarbeitet.
EDIT: Ich habe es gefixt und nach einem Update bitte erneut prüfen! Version 1.21
ALLES WEITERE dann HIER BITTE! (https://forum.fhem.de/index.php/topic,85137.0.html)
Moin Moin von der Nordsee,
habe Fhem für mich entdeckt. Bekomme meine FHT nicht gepairt oder sie fallen nach einiger Zeit raus.
Habe mir das Modul xs1 "aufgezogen" und bin begeistert weil ich alles was mit Fhem nicht ging habe.(Wetterstation usw)
Nun weiss ich nicht wie ich die FHT 80b ansteuern kann um die Temparatur zu verändern.
Hoffe das es noch jemand liest weil seit 120 Tagen nichts mehr geschrieben worden ist.
Viele Dank
Hallo aus Mitteldeutschland :)
da ich das Modul schrieb damals habe ich deine Frage vernommen :) Hast du nur ein Modul in Benutzung oder beide?
Es gibt's xs1_Device und xs1_Bridge. (Namen können geringfügig variieren weil ich derzeit kein Rechner in der Nähe habe) Das eine Modul liest für dich aus und das andere steuert die xs1 welche für dich dann die Sendekommandos zu den Devices übernimmt.
Die Kommunikation zwischen FHT80b und xs1 besteht? Kannst du diesen über die xs1 steuern?
Lg
Gesendet von iPhone mit Tapatalk Pro
Hallo,
wow du hast aber sehr schnell geantwortet. ;D
Deine Info mit den beiden Modulen helfen mir hoffentlich weiter.
Habe leider nur das Bridge Modul am laufen. werde gleich mal das zweite aufsetzen.
Die FHT`s kann ich mit der Xs1 steuern.
Viele Dank erstmal.
Schön, dass es doch wieder jemand gibt, der dem XS1 die Treue hält. Dachte ja sehr lange, ich sei der einzige mit der Kombination des XS1 mit FHEM. Dann kam irgendwann doch dieses Modul. Zugegeben, ich nutze es (noch) gar nicht. Ganz einfach: Die wenigen Schnittstellen, die ich nutze, hatte ich zwischenzeitlich mit Workarounds gelöst.
Zu den FHT: Diese hatte ich seinerzeit aber auch mit dem XS1 nicht wirklich immer dauerhaft stabil. UNd trotz regem Kontakt mit dem diesbezüglichen Support direkt vom Hersteller habe ich das nie zur vollen Zufriedenheit hinbekommen.
Jetzt habe ich alle FHTsmittlerwele nur noch über FHEM ohne XS1 laufen. Hier habe ich gelernt zu akzeptieren, dass alle paar Monate mal Kontaktprobleme auftauchen. Diese können sich mal über Tage hin ziehen, manchmal dann auch gleich wechselweise bei unterschiedlichen FHTs auf einmal. Dann geht aber gleich wieder für Monate alles gut.
Bei Dir ist es so, dass Du mit dem XS1 den Kontakt problemlos hälst, FHEM aber Schwierigkeiten macht, ist das richtig? Du hast die Kopplung aber auch schon erfolgreich geschafft, also ein Bedienerfehler ist praktisch ausgeschlossen, richtig? Wieviele davon betreibst Du denn?
Ist alles etwas grenzwertig zu OT, aber bin doch neugierig.
Hallo duke-f.
Die habe ich mir 2010 bei Aldi im Set mit Fensterkontakten gekauft. Ich fand die Dinger gut, weil die mit Batterien und Funk laufen.
Sehr viel Später bin ich darüber gestolpert das man alles auch mit dem PC steuern kann. Habe mir dann eine xs1 zugelegt und bin bisher immer zufrieden damit gewesen. Alle paar Wochen muss ich sie neu Starten weil sie hängen bleibt. Habe mir dazu dann noch so einige Dinge zugekauft, eine Wetterstation, Steckdosen, Schalter, Jalousieschalter usw. was man zum Spielen so braucht. ::)
Auf Fhem bin gekommen weil man damit eine Grafische Oberfläche gestallten kann wo man die einzelnen Sensoren und Aktoren sehen und schalten kann.
Das Pairen habe ich schon geschafft. Habe erstmal es mit zweien zum probieren versucht. Das klappte nach einer weile gut.
Am nächsten Tag aber leider nicht mehr. Das neu koppeln wollte dann bei einem überhaupt nicht mehr und der andere nur nach einem neustart des Pi3.
Betreibe 13 FHT bisher problemlos.
LG Andy
Zitat von: Andysh am 13 April 2019, 10:49:40
Hallo,
wow du hast aber sehr schnell geantwortet. ;D
Deine Info mit den beiden Modulen helfen mir hoffentlich weiter.
Habe leider nur das Bridge Modul am laufen. werde gleich mal das zweite aufsetzen.
Die FHT`s kann ich mit der Xs1 steuern.
Viele Dank erstmal.
Kein Problem :) und danke der Technik wird man ja benachrichtigt.
Das Konzept der Module ist wie folgt, die Bridge liefert Dir die Zustände aller x Zeit (einstellbar) ans Fhem. Weil es User gibt die nicht nur auswerten, sondern steuern wollen, so kam das 2 xs1 Modul dazu. Beide sind notwendig um zu steuern :)
Gesendet von iPhone mit Tapatalk Pro
Na gut, 13 sind schon viele. Ich dachte, meine 7 sind schon viel. Irgendwo steht auch was dazu, wieviele FHTs problemlos mit einem Sender/Empfänger zu schaffen sind, weil die Länge der Übertragungen recht groß sind, z.B:
https://wiki.fhem.de/wiki/FHT_mit_RFR_CUL_pairen
Oder hier werden als praktisch realsisierbar 10 genannt, theoretischer Grenzwert 17:
https://wiki.fhem.de/wiki/FHT80b
Ich habe bei mir an einem CUL 4, am einem anderen CUL 3 FHTs hängen. Aber wie Du sagst, ist das XS1 da ja großzügiger. Das betrifft meiner gefühlten Erfahrung zur Folge auch die Grenze der erlaubten Belastung des Frequenzbandes.
Sicher hast Du die spezifischen Treads zu den Problemen mit FHT schon durchforstet, wenn Du seit 2010 damit zugange bist.
Meine Historie war ja anders herum: Ich suchte nach einer Variante, externe Festplatten von außerhalb zu steuern und kam dann auf das XS1 mir den QUIGG-Aldi-Steckdosen. Dann habe ich entdeckt, dass ich diese FHTs damit steuern könnte und der Spieltrieb lies sich nicht mehr bremsen. Eigentlich habe ich das aber immer noch so in Erinnerung, dass die FHT-Probleme die Leute eher weg vom XS1 zu FHEM getrieben hat. Ist aber alles schon lange her.