@Homoran: Und nochmal Immer zuerst den js-controller und dann den admin updazen. ` Deswegen hatte ich heute auch wieder ein weißes Bild. Man updatet automatisch alles was an Adaptern aufleuchtet und denkt nicht daran, erst den Host zu updaten. Das muss irgendwie anders gelöst werden. Das ist eine Falle, in die jedesmal auch erfahrene User stolpern und die Anfänger total abschreckt.

@MrLee: Könnte der SQL-Adapter nicht vorm schreiben prüfen ob der Wert (Timestamp, Datenpunkt, value) schon da ist? ` Aus Performancegründen würde ich das nicht einbauen wollen … Also ich habe es so gelöst das ich ein Warm-Standby System habe. Für die States nehme ich Redis und da ist auf dem Warm-Standy ein Redis-Slave. Damit sind mal alle State-Daten da. Der Redis ist mit einer Zeile in der Konfig zum Master gemacht. ioBroker-Daten(also das Verzeichnis) an sich wird regelmäßig per rsync auf den Warm-Standby Rechner gesynct der hat HW- und OS-mäßig identisch ist zum Hauptsystem. Da ändert sich aber im Normalfall nur das objects.json. Heisst im Notfall reicht dort ein fixen des Hostnamens in der iobroker-Konfig und der Master läuft wieder. Für die Slaves hab ich nen DNS-Eintrag der auf den Master zeigt mit dem die Verbunden sind (ebenso für Redis). Also mit Ändern des DNS-Eintrags ist es auch gefixt. Sind also ein paar Handgriffe leider, und auch welche die blöd zu automatisieren sind. Die "Multi-Master"-Idee ist schon in einigen Köpfen, aber hier ist meiner Meinung nach ganz wichtig nicht zu wenig zu machen, weil man sonst zu schnell in komische Situationen kommt. Theoretisch müsste man eine Quorum-Logik bauen und das heisst das mindestens 3 Rechner nötig sind um zu sagen ob der aktuelle Master wirklich tod ist und sich auf einen neuen zu einigen falls man das automatisieren will. Das kann alles beliebig komplex werden. Mal schauen.

[image: 452_screenshot.165.png] hmm - tja nun ist sie wieder bei Dir. Auch gut. :lol:

Hallo, ok, dann mache ich mal einen Thread dazu auf. Gruß Sven

Habe hier einen neuen Thread in der Entwicklung aufgemacht. http://forum.iobroker.net/viewtopic.php?f=24&t=5599 Vielleicht kann ein Admin diesen schließen. Dankeschön.

Oh Sorry, hatte das hier aus den Augen verloren. Gut, dass du schon die Lösung hast! Vorrausgesetzt das zu beschreibende Object hat den Typ Boolean (auf Deutsch: Logikwert), und nicht etwa Mixed, sollten "true" und "false" funktionieren. Oder du hast einen Bug gefunden. :?:

Wir haben ne Thread Dublette … bitte unter http://forum.iobroker.net/viewtopic.php?f=22&t=5588 weitermachen :-)

Sorry Jungs; bin eben eher der "ich möchte wissen was" Typ ;-) Hab keine Sekunde darüber nachgedacht, dass 0.0.0.0 auch gehen würde. Was zwar Sinn macht… aber s.o. :mrgreen:

Danke für den Tipp. Ich prüfe das mal. Was mir auffällt ist, dass in den Ereignissen kurz vor dieser Meldung immer das Datum mit Jahr 1970 und Uhrzeit 00:00h ausgegeben wird. Sobald die erste Meldung wieder mit korrekter Zeit erscheint, kommt der Fehler Beispiel: stateChange hm-rpc.0.KEQ0xxxxx.2.BOOT true true hm-rpc.0 2017-03-08 11:40:01.477 2017-02-11 16:15:00.835 stateChange hm-rpc.0.GEQ0xxxxx.0.UNREACH_ALARM false true hm-rega.0 1970-01-01T00:00:00.000Z 1970-01-01T00:00:00.000Z stateChange hm-rpc.0.GEQ0xxxxx.0.STICKY_UNREACH_ALARM false true hm-rega.0 1970-01-01T00:00:00.000Z 1970-01-01T00:00:00.000Z stateChange hm-rpc.0.GEQ0xxxxx.0.LOWBAT_ALARM false true hm-rega.0 1970-01-01T00:00:00.000Z 1970-01-01T00:00:00.000Z stateChange hm-rpc.0.GEQ0xxxxx.0.DUTYCYCLE_ALARM false true hm-rega.0 1970-01-01T00:00:00.000Z 1970-01-01T00:00:00.000Z stateChange hm-rpc.0.GEQ0xxxxx.0.CONFIG_PENDING_ALARM false true hm-rega.0 1970-01-01T00:00:00.000Z 1970-01-01T00:00:00.000Z stateChange hm-rpc.0.KEQ0xxxxx.1.ERROR-7_ALARM false true hm-rega.0 1970-01-01T00:00:00.000Z 1970-01-01T00:00:00.000Z stateChange hm-rpc.0.KEQ0xxxxx.1.ERROR-6_ALARM false true hm-rega.0 1970-01-01T00:00:00.000Z 1970-01-01T00:00:00.000Z stateChange hm-rpc.0.KEQ0xxxxx.1.ERROR-5_ALARM false true hm-rega.0 1970-01-01T00:00:00.000Z 1970-01-01T00:00:00.000Z stateChange hm-rpc.0.KEQ0xxxxx.1.ERROR-4_ALARM false true hm-rega.0 1970-01-01T00:00:00.000Z 1970-01-01T00:00:00.000Z stateChange hm-rpc.0.KEQ0xxxxx.1.ERROR-3_ALARM false true hm-rega.0 1970-01-01T00:00:00.000Z 1970-01-01T00:00:00.000Z stateChange hm-rpc.0.KEQ0xxxxx.1.ERROR-2_ALARM false true hm-rega.0 1970-01-01T00:00:00.000Z 1970-01-01T00:00:00.000Z stateChange hm-rpc.0.KEQ0xxxxx.1.ERROR-1_ALARM false true hm-rega.0 1970-01-01T00:00:00.000Z 1970-01-01T00:00:00.000Z stateChange hm-rpc.0.KEQ0xxxxx.0.UNREACH_ALARM false true hm-rega.0 1970-01-01T00:00:00.000Z 1970-01-01T00:00:00.000Z stateChange hm-rpc.0.KEQ0xxxxx.0.STICKY_UNREACH_ALARM false true hm-rega.0 1970-01-01T00:00:00.000Z 1970-01-01T00:00:00.000Z stateChange hm-rpc.0.KEQ0xxxxx.0.LOWBAT_ALARM false true hm-rega.0 1970-01-01T00:00:00.000Z 1970-01-01T00:00:00.000Z stateChange hm-rpc.0.KEQ0xxxxx.0.CONFIG_PENDING_ALARM false true hm-rega.0 1970-01-01T00:00:00.000Z 1970-01-01T00:00:00.000Z stateChange hm-rpc.0.EEQ0xxxxx.1.ERROR-2_ALARM false true hm-rega.0 2017-03-08T07:44:25.000Z 1970-01-01T00:00:00.000Z stateChange hm-rpc.0.EEQ0xxxxx.1.ERROR-1_ALARM false true hm-rega.0 2017-03-08T07:44:25.000Z 1970-01-01T00:00:00.000Z

@foxthefox: Unabhängig was dahinter steht. Es eine clevere Übersicht der unterstützten Dinge. ` Da hast du recht und sowas gibt es ja auch auf der ioBroker Seite. Leider ist da nicht mehr zu sehen weil die Hersteller/Anbieter der Nutzung ihrer Logos zustimmen müssen und das haben wohl einige abgelehnt.

Problem dank Soef gelöst. Es war uPNP auf der Fritzbox nicht an. Danach ging es.

Auch eine Variante, hab mir das Feld hinter das Pumpem Widget gelegt. Schade das es mit dem Widget selbst nicht geht aber so reicht es auch. Danke ykuendig

Also es läuft nun, ich habe alles unter /opt nochmal gelöscht und dann von vorne angefangen. Anscheinend habe ich beim ersten mal tatsächlich versucht unter /opt zu installieren. Von diesem Versuch gab es anscheinend noch Reste, die jetzt zu Problemen geführt haben. Danke für eure Hilfe. Gruß, jawr

Bei mir haben sich die obigen Settings im Redis aber als guter "Notnagel" erwiesen weil im Notfall der Redis Server einfach eine Verbindung killt sobald die bei 512MB ausstehender Daten landet … damit hat er sich nie wieder aufgehängt. Und am Ende startet sich maximal der verursachende Adapter neu ... also auch zu verkraften. Schreibst Du "gelöst" bitte noch ins Thread Subject?! Danke

ok, ich habs, dass war es :) Danke, geht nun.

@Bluefox: @Homoran: Hallo Bluefox, Wäre das hier zum testen etwas für dich - wenn noch verfügbar: http://homematic-forum.de/forum/viewtop … =7&t=34953 Gruß Rainer ` Letztendlich es soll jetzt schon gehen und ich sehe, dass bei eric geht es. Mir reichen wirklich die RawDaten (mit Config Beschreibung: COC/CUL, Mode, …) um die Feature zu implementieren. ` besteht noch Bedarf an den RAW Daten von MAX!-Geräten? Habe die aktuell noch mit einem CUL unter FHEM laufen. Steuerung über IoBroker läuft auch schon. CULs habe ich insgesamt 3 Stück. einen CUL 433 MHz für Intertechno Steckdosen, einer für 868 MHz FS20 Geräte im SlowRF mode und einen für 868 MHz MAX!-Geräte im rfmode MAX. Damit kann ich gerne weiterhelfen.

Da bin ich ja beruhigt. :mrgreen: Du müsstest dann nur ein neues Board errichten ganz unten. "Uservorstellungen" oder so.

axo

Also ich habe meine von hier https://sourceforge.net/p/fhem/code/HEA … Reader.zip Einfach das ZIP Downloaden/ entpacken und auf den Jeelink draufpacken Gruß Adrian Gesendet von iPhone mit Tapatalk Pro

Das ist eine gute Frage :-) Ich würde es mal so formulieren: Wir versuchen gerade im Trello alles "aktuelle" zu haben an dem gearbeitet wird, und die interessanten DInge der Zukunft … Von daher ist Trello gerade eher der Anlaufpunkt, aber am Ende ist es noch in der Findungsphase :-) Neue Jira-Tickets bekomme ich auch und versuchen Sie zu überführen bzw. zu checken. Trello: Dort Account machen und mir den Trello-Namen per PN schicken, Dann schalte ich Dich frei.