Danke für die schnelle Antwort, leider habe ich aber ab dem Punkt null plan wie ich mir die Temperaturwerte in io.broker anzeigen lassen kann :( edit: hat sich erledigt habe die falsche Sensor ID eingetragen ;)

@Bluefox: Es ist sehr merkwürdig, was du machen willst. Auch wenn du dein Adapter stoppst, der wird nach 30 Sekunden von Controller neu gestartet. adapter.stop ist gedacht für die Adapter, die Zyklisch laufen. Und wenn jetzt gestartete Adapter seine Arbeit erledigt hat, dann kann er sich selbst mit adapter.stop stoppen (bis zu nächsten Schedule Event) Wenn du unbedingt Adapter stoppen willst, dann kannst du das Objekt system.adapter.ADAPER_NAME.x editieren, so dass common.enabled false wird, dann wird Adapter vom Controller gestoppt. BTW: Man kann auch Adapter aufwachen lassen, wenn ein Zustand sich ändert. ` Danke für deine Erklärung….hat sich auch erledigt!

@Bluefox: Warum man die Objekte beim jedem Start nicht löschen sollte, weil im Objekt auch History, Mobile und andere Sachen gespeichert werden. Nach dem Löschen muss man seine Logging dann wieder einstellen. ` Klingt logisch…. Danke für das Beispiel! Ich glaube damit schaffe ich es :idea:

Bald ist Weihnachten …

So, jetzt bin ich endlich mal wieder zum weiter Testen gekommen. Ein Stückchen weiter bin ich. Natürlich - die Argumente hatten gefehlt :oops: Den Adapter hatte ich im ioBroker selbst schon gestoppt. Jetzt sieht's beim Starten des Debugs so aus: [image: 250_startdebug2.jpg] Wenn ich in adapter.on('ready', function () { main(); }); einen Haltepunkt setze wird der auch ausgeführt. Aber die Haltepunkte darunter werden nie ausgeführt, nichts ins Log geschrieben etc. wenn ich im ioBroker etwas an den Adapter sende. Irgendwie hab ich wohl noch keine Verbindung zum ioBroker - hat das noch was mit dem Port zu tun, auf dem der Debugger lauscht? Wie schon gesagt - ich stelle mich bestimmt nur dämlich an, aber irgendwie sind hier die Zusammenhänge noch nicht in mein Gehirn geschnippt :cry:

Erledigt. Gruß, Eric

Hallo Bluefox, so meine ersten Änderungen sind raus. Ich bin mal gespannt ob man damit etwas anfangen kann. Wenn ich alles richtig gemacht habe, dann würde ich die Metro Widgets noch ein wenig weiter "aufräumen". Gruß Michael

in …\iobroker.admin\www\js

Hallo Trident, ich fand die Hürde zur Erstellung eines Adapters auch recht hoch. Ich empfehle dir, zuerst ein Github-Konto zu erstellen. Dann kopierst du dir von der ioBroker-Github Seite einen funktionierenden Adapter, der ungefähr deinem geplanten Adapter entspricht, auf die Festplatte und schaust dir die Dateien mal an. Du kannst zum Beispiel mit den Adapter-Einstellungen beginnen (/Admin/index.html). Ich habe meine Adapter bisher ohne Entwickler-Umgebung gebaut. In der ioBroker Admin Konsole kannst du mit dem Github Knopf (die Katze) dann einen eigenen Pfad/URL für den Adapter definieren und von dort laden. Und schließlich kannst du deinen Adapter mit der Github App für dein Betriebssystem auf dein Github Konto hochladen. Dann können andere mal drüber gucken. Bleib dran, beiß dich durch! Gruß Pix

Hallo zusammen, ja, "fertige" Images würden einem Anfänger und bekennendem Linux-DAU wie mir einen Start deutlich vereinfachen. Es ist mittlerweile schon ein paar Wochen her, dass ich mich endlich an eine neue Installation von ioBroker gewagt habe. Nach einer schon länger zurückliegenden Erst-Installation auf meinem Syno-Eigenbau (Stichwort: xpenology) habe ich irgendwann die "Arbeit" mit ioBroker eingestellt, bzw. die regelmäßigen Updates. Zum Einen gab es eine Phase in der ich viel von Problemen/Ausfällen nach Updates gelesen habe (insbesondere Admin-Adapter und js-controller), zum Anderen kommt der Syno-Eigenbau z.Zt. immer noch nicht über DSM 5.2 hinaus und damit ist Node 4.x nicht im Paketzentrum verfügbar, die für ein aktuelles ioBroker ja erforderlich ist. Manche Adapter ließen sich auch gar nicht erst installieren (z.B. Harmony). Nachdem es mich irgendwann lang genug gewurmt hat, dass ich das nicht so nutzen kann wie ich gern würde, habe ich mir einen CT zugelegt und einfach mal aufs Geratewohl angefangen. Leider kam die Meldung über in aktualisiertes Image für den CT ganz knapp zu spät. Ich war quasi mit dem Grundgerüst fertig als ich das gelesen habe. Machte letztlich aber eigentlich nichts. Habe mich da eben manuell durchgebissen. Hat zwar gefühlt ewig gedauert und mehrerer Anläufe bedurft, aber dümmer bin ich dadurch auch nicht geworden. Nachdem der CT ohne Murren zuverlässig lief und auch alle Adapter aktuell, bzw. nutzbar waren, plagte mich die Sorge, dass durch einen Update-Crash und dessen Folgen irgendwann der WAF in den sprichwörtlichen Keller fallen könnte. Ist schließlich in anderen Dingen schon oft genug passiert und mit der Umstellung von ccu.io/dashui auf ioBroker mute ich der Regierung schon genug zu. Habe dann nach Möglichkeiten für ein Zweit-/Testsystem Ausschau gehalten. Um nicht noch weiter ins OT abzuschweifen: Es ist ein "alter" Intel NUC (DN2820FYKH) geworden. Direkte Installation von Debian, keine VM. Der ist jetzt das Produktivsystem und der CT das Testsystem, auf dem Neuerungen zuerst ausprobiert werden. Danke an @Brati an dieser Stelle für die Hilfe und Hinweise das System ans Laufen zu bekommen! Um zum eigentlichen Thema zurückzukehren: Fertige Images erleichtern einen Start in die Welt von ioBroker ungemein, daher möchte ich klar für deren Erstellung und Pflege votieren. Danke, dass Ihr Euch die Arbeit macht und so versucht auch "Nicht-Linuxer" mitzunehmen.

Hallo Rainer, Wusste jetzt nicht genau ob das hier rein passt. Ich guck gerade bein meinen freunden rum, wer sich sowas zutraut. Ist ja nicht nur die steuerung, innogy fehlt ja quasi auch noch … Bleibt ja nix anderes über als selber zu machen ... bzw machen lassen. Gruss, Riccardo

Ich habe das Problem erst einmal anders gelöst und lasse das "importer"-skript nicht unter "InfluxDB" laufen sondern unter Histoyr (also History sendet seine Daten an InfluxDB … macht auch sinn so rum). Und damit ist das Problem vorläufig gelöst das ein Adapter an sich selbst Messages sendet :-)

https://crosswalk-project.org/jira/browse/XWALK-7195 Vielleicht passiert was.

So, habe die Hue Bridge und 2 Osram Lightify Schaltsteckdosen miteinander verbunden und erfolgreich in iobroker angebunden. Danke für die Hilfe! Klappt perfekt. Zwar dauert die Umsetzung der Befehle etwas, weil Hue scheinbar Fremdanbieter etwas verzögert, aber das ist im Rahmen. Nur etwas schade. Schade ist auch, dass HUE es nicht über Siri zulässt, Lightify Zubehörteile zu steuern.

@apollon77: Sollte "getForeignObjects" denn funktionieren? Oder geht das nur mit CouchDB? Ich teste nochmal mit nem sauber "original" Installierten Adapter mit Schedule. Mal schauen … vllt tuts ja doch magisch ` Api ist komplett kompatibel. Das was bei couchdb geht, geht auch mit Objekten. getForeignObjects sollte gehen.

Habe jetzt vorübergehend mal dieses "Webinterface" eingebunden: grauonline.de/alexwww/indego/indego.html das funktioniert super und basiert anscheinend komplett auf Javascript. Allerdings kann ich da natürlich nichts weiter mit den Datenpunkten Anfangen. Wäre es für die Profis hier ein großes Problem da einen Adapter für ioBroker zu zaubern? Sorry kenn mich wie gesagt nicht wirklich aus.[emoji17]

Ok. Ich habe Doku angefangen: https://github.com/ioBroker/ioBroker.ja … ckly_en.md Es gibt zwei Möglichkeiten: Erweitern auf english Übersetzten auf deutsch. Beides ist Willkommen. Auf github.

Nö, die lib ist unverändert. Der code liegt hier: https://github.com/ruhigundrelaxed/ioBroker.eibd In eibd.js gibt es die auskommentierte function: recurseQueue Da hab ich versucht die queue rekursiv, ohne setInterval abzuarbeiten. Hat leider nicht funktioniert.. weil halt "zu" asynchron…(galube ich zumindest) :roll: ..ist nur noch nicht aufgeräumt. > …250 ms, dann mit setTimeout warten bis 250 Intervall erreicht wird. wird mir nicht ganz klar. Aber es geht in die Richtung: setInterval pausieren zu lassen wen buffer leer, und resumen wenn buffer nicht leer? du bildest seInterval mit setTimeout nach?!? Ok. Das könnt ich probieren…. Danke.