Hi,

besteht Interesse an einer Erweiterung des bestehenden Fully-Adapters durch MQTT?

Der Adapter nutzt nämlich nur die REST API. Über MQTT können jedoch Status-Änderungen quasi in Echtzeit angezeigt werden, etwa Bewegungsmelder, etc.

Interessant wäre es auch, Datenpunkte wie etwa "screenOn" und "screenOff" zu kombinieren in einen Switch, der dann auch stets den aktuellen Status anzeigt.

Screenshot (Zwischenlösung von mir mittels MQTT-Adapter und JS)

Also, besteht Interesse? Dann mache ich mich gerne dran, habe bereits ein Adapter Prototypen-Gerüst vorliegen mit implementierter REST-API und in TypeScript, als Basis, um MQTT einzubauen.

@arteck - ich würde das dann am liebsten natürlich im bestehenden Adapter von dir machen. Oder was meinst du, auch generell zu der Idee?

@mattb
Ich stelle demnächst einen Link hier ein (Github), also TypeScript-Adapter. Vorher möchte ich noch ein paar erste Fehler abfangen und besseres Debug Log einbauen.
Bitte sehr gerne beteiligen an der Entwicklung, das wäre cool. MQTT ist für mich Neuland, aber @rovo89 hat halt mega gute Vorarbeit geleistet mit seinem Proof of Concept und der Entschlüsselung.

Hi. Ich bin derzeit unerwartet mit einer Renovierung und Innenausbau beschäftigt, daher derzeit nicht wirklich Zeit für den Adapter.
Ich war auch schon etwas weiter, nur hatte ich fälschlicherweise zwischendurch in einem Temp-Verzeichnis ohne Backup entwickelt, alles weg.

Aber ich hatte noch eine Version vom November, und diese jetzt hochgeladen auf Github und Dependencies aktualisiert etc.

Link: https://github.com/Acgua/ioBroker.roborock

Installation

Manuell, über "Installieren aus eigener URL", "Benutzerdefiniert". Dort den Link eingeben. Danach eine Instanz installieren.

Einrichtung

In den Admin-Optionen Benutzernamen (bzw. Email) und Passwort von Roborock eingeben, also die Account-Daten von der App.

Die Instanz wird danach ein gelbes Dreieck zeigen.

Es werden einige Objekte unter roborock.0 angelegt, aber alle unter <id>.info sind derzeit noch leer.

Die Objekte roborock.0.homedata und roborock.0.userdata sollten aber Werte haben.
Hier könnten Tester mal prüfen, ob Werte ankommen.
Im Fall auch das Debug-Log aktivieren und ins Log schauen.

Weiter geht diese Version des Adapters noch nicht.
Ich werde nächstes Jahr wieder weiter entwickeln, aber gerne kann jeder dies als Basis für eine Weiterentwicklung nehmen, forken, was auch immer. Nur bitte dann hier kurz reinschreiben im Thread, wenn wer von euch weiter oder neu entwickelt.

@rovo89 - Vielen Dank hierfür, Wahnsinn

Läuft super. Ich habe es gar nicht erst in node.js selbst getestet, sondern gleich deine Scripts in einen noch zu entwickelnden Adapter eingebaut (TypeScript). Erst mal nur zum Testen.

Ich werde daraus noch entsprechend einen Adapter-Vorschlag bauen.

Viel ist noch nicht da, zunächst lasse ich nur mal States erzeugen aus den verfügbaren Daten.

Ich melde mich hier wieder, sobald ich weiter bin.

Hallo,

ich verwende als Server für ioBroker, usw. einen Barebone mit Proxmox.
Mich störte dabei, dass die Festplatte unverschlüsselt ist. Bei Diebstahl kann so zu einfach auf die Daten zugegriffen werden, ebenso ggf. ein Risiko bei Festplattendefekt, wenn diese Platte dann vom Müll/Wertstoffhof in die entsprechenden Hände kommt.

Daher habe ich den Server neu aufgesetzt: Debian installiert mit "Geführt - gesamte Platte mit verschlüsseltem LVM" (also LUKS-Verschlüsselung), darüber dann Proxmox installiert gemäß https://pve.proxmox.com/wiki/Install_Proxmox_VE_on_Debian_11_Bullseye.

Beim Serverstart verbinde ich mich dabei von Windows aus via SSH und gebe die Passphrase ein. Damit das möglich ist, habe ich noch dropbear installiert und eingerichtet.

Ich habe alle Schritte mitdokumentiert und zuerst auf Testsystem getestet. Besteht Interesse an einer Veröffentlichung einer Schritt-für-Schritt-Anleitung?

Hi,

vielen Dank für den Adapter, läuft bislang sehr gut, bin begeistert!
Ich bin umgestiegen vom Zigbee-Adapter, mit 30+ Geräten, ConBee II Stick.

Meine Vorgehensweise für Proxmox-Container in etwa:

Proxmox-Container vorbereiten:

• Debian 11 Container erstellt: 512 MB RAM, 512 MB Swap, 4 GB HD-Speicher, 1 Kern
• apt update -y && apt upgrade -y, apt install -y sudo usbutils curl git (und ggf. paar mehr benötigte Pakete)
• adduser z2m, adduser z2m sudo, su z2m (ab jetzt nur noch User z2m nehmen, nicht mehr root)
• USB-Stick (ConBee II) durchreichen gemäß ioBroker-Doku

Mosquitto in Container installieren:

(angelehnt an diese Anleitung)

• sudo apt install -y mosquitto mosquitto-clients
• Auto-Start einrichten: sudo systemctl enable mosquitto.service
• Enable Remote Access (No Authentication): sudo nano /etc/mosquitto/mosquitto.conf und die Zeilen listener 1883 und allow_anonymous true am Ende der Datei eintragen. (Notiz an mich selbst: auf auth umstellen!)
• Mosquitto neu starten: sudo systemctl restart mosquitto
• Status prüfen: systemctl status mosquitto
• sudo reboot, dann mit systemctl status mosquitto prüfen, ob Mosquitto automatisch startet.

Zigbee2MQTT in Container installieren:

• Vorgehensweise in etwa gemäß der offiziellen Anleitung für Linux. Wichtig: gemäß Anleitung wird NodeJS 16 installiert (...setup_16.x), ich habe das auf 18 geändert (wird offiziell supported)
• Konfiguration in /opt/zigbee2mqtt/data/configuration.yaml nach Anleitung gemacht, dabei als MQTT server server: 'mqtt://localhost' eingetragen
• Eingerichtet, dass Zigbee2MQTT automatisch beim Booten startet gemäß Doku.
• sudo reboot, dann mit systemctl status zigbee2mqtt.service prüfen, ob Zigbee2MQTT automatisch startet.

ioBroker Zigbee2MQTT-Adapter

• Vorgehensweise gemäß Doku - Installation inkl. Umzug vom ioBroker/Zigbee Adapter
• Wichtig, falls ConBee II Stick: configuration.yaml nochmal anpassen:
  1. Unter serial eintragen: adapter: deconz
  2. Unter advanced die Zeile transmit_power: 20 löschen, das scheint der ConBee II nicht zu können und es kommen Fehler beim Start von Zigbee2MQTT

Screenshots

Proxmox (letzter Neustart war erst vor 50 Minuten). Schön geringer Ressourcenbedarf.

Adapter-Instanz-Einstellungen

EDIT (KORREKTUR) - 09.08.2022:

Es gibt einen neuen Windows Installer zum Testen, siehe hier:
Test ioBroker unter Windows installieren - 2022 Edition

Daher ist untenstehende Anleitung nicht mehr gültig/notwendig, bitte testet stattdessen den neuen Installer und gebt Feedback. Danke.

URSPRÜNGLICHER BETRAG - 08.08.2022:

Funktionierende Anleitung (August 2022): Installation von ioBroker mittels Installer unter Windows 10
https://github.com/Acgua/ioBroker-Doc/blob/main/windows-10-new-installation.md

Hier eine aktuelle inoffizielle Anleitung von mir, mit der ich am heutigen 08.08.2022 ioBroker unter Windows erfolgreich mit dem alten 2019er Installer installieren konnte. Alles andere hatte nicht gefruchtet, also nicht die Vorgehensweisen wie hier, hier, hier oder hier(PDF) beschrieben.

Hinweis: So hat es halt in meiner Umgebung funktioniert, bei euch aber vielleicht so nicht. Aber hier schon mal ein Versuch, das ganze auf Github aktuell zu halten, anstatt verstreut über zahlreiche Foren-Einträge, statische PDF als Attachment, etc.
Ich wäre um eine Mitarbeit dankbar, zumindest bis es einen neuen Installer gibt. Ihr könnt gerne auch Github-Issues öffnen für Anregungen etc.

(An Moderatoren: ich habe diesen Beitrag in insg. 3 Threads gepostet im Sinne der Übersichtlichkeit und zur Zusammenführung des Konsens. Falls nicht gewünscht: bitte gerne löschen! Danke.)

@alcalzone
Hi! Vielen Dank für deine Antwort und auch die Beispiele!
Sehr hilfreich und beantwortet alle Fragen.
Hab jetzt am Anfang schon mega Lust in TS was zu entwickeln statt in plain JS, weil ich damit endlich viel sauberer arbeiten kann usw. und mir einiges an weniger Fehler etc. erwarte. Ich bin in Begriff, einen ersten Adapter zu schreiben, und diesen halt gleich in TS und nicht JS.

@mcm57 said in Rules vs SmartControl:

-) Wer benutzt den Smart Control Adapter und was fehlt ihm/ihr an dem ?

(a) Ich (b) Mir fehlt nichts, toll, dass er wieder weiter "maintained" und entwickelt wird - vielen Dank @oelison und Team!

-) Wer benutzt Rules und was fehlt ihm/ihr dort ?

Ich benutze Rules gar nicht. Evtl. gab es auch zu wenig "Marketing" bei der Rules-Einführung, so dass dies bisher wohl wenig Beachtung fand hier im Forum und in der Szene insgesamt. Aber nur so eine Vermutung. Amerikanische Smarthome-Systeme hätten das wohl gefeiert und gefühlt gleich mal einen Mega-Event in Vegas veranstaltet

-) Und vor allem Warum kann er/ sie nicht die andere Möglichkeit benutzen?

• Smart Control hat bereits einige Logiken unter der Haube vor allem auch bezüglich Bewegungsmelder und Lichtsteuerung etc. Das ist tatsächlich eher aufwändig, mit JS / Blockly / wohl auch Rules / etc. abzubilden, damit es stabil läuft. Auch lassen sich dann leicht neue Geräte, Räume, etc. hinzufügen, sobald man mal alles aufgesetzt hat.
• Schedules lassen sich schön und komfortabel konfigurieren: Tage, Uhrzeiten oder Astro, "nur wenn Feiertag heute", "Nie schalten wenn Putzfrau im Haus" etc.
• Stabilität: Alles eingeschränkter als in JS/Blockly etc., aber dafür ausreichend mit dem Adapter getestet und erprobt, viele Überprüfungen sind bereits eingebaut (existiert Datenpunkt noch, ack-Handling, usw.) und man bekommt übersichtlich die jeweiligen Fehler ausgegeben

Was es meiner Meinung nach nicht braucht sind noch mehr Sonderwünsche, die umgesetzt werden. Man erkennt da teilweise schon sehr spezielle Use Cases in den Optionen und ich vermute, dass diese die Mehrheit nicht verwendet. Der Aufwand an Maintenance steigt dadurch erheblich....

Fazit:
Mal schnell eben einen neuen Flur mit Bewegungsmelder, 2 Lichtschalter und Leuchten einbinden, da würde ich Smart Control vor allem anderen wählen. Wäre wohl eine Sache von ein paar Minuten im SC, und würde wohl deutlich länger dauern in JS/Blockly,..., auch wenn man bereits ein ähnliches Script hat. So halt meine Erfahrung.

MOD-EDIT: Dieser Adapter wird nicht mehr gepflegt. Bitte hier https://forum.iobroker.net/topic/69729/fullybrowser-3-0 weitermachen

Edit, 24.03.23: Update auf 0.0.11
Edit, 14.03.23: Update von 0.0.1-alpha auf 0.0.4

Siehe Forum-Thread Fully Browser Adapter: MQTT?

Dieser Adapter basiert auf den Fully-Adapter von @arteck, habe ich aber komplett neu geschrieben in TypeScript.

Der bisherige Adapter nutzt nur die REST API, diese neue Testversion bietet nun auch optional an, dass man MQTT nutzt zum Empfang von Daten.
Dank MQTT kommen nun Status-Änderungen wie Bildschirm an/aus oder Bewegungsmelder quasi in Echtzeit in den Datenpunkten an.

(Senden von Commands erfolgt weiterhin nur über die REST API, da der Fully Browser dies über MQTT nicht unterstützt.)

Neben MQTT ein Auszug aus weiteren Neuerungen im Vergleich zum bisherigen Adapter:

1. Datenpunkte wie screenOn / screenOff usw. werden mit ack:true bestätigt, wenn das Setzen erfolgreich war. Dies ist hilfreich, um etwa in VIS dies entsprechend darzustellen.
2. Objekte (Datenpunkte) werden nicht mehr im Format fullybrowser.0.192_168_10_10... angelegt (also nicht mehr anhand IP), sondern anhand des Namens, also etwa fully-mqtt.0.Tablet-Flur.... Für Abwärtskompatibilität kann man im Namen die IP mit Unterstrich statt Punkt setzen, siehe hier 2. Zeile.
   
3. Mehrere Commands / Status sind zusammengefasst, wie etwa fully-mqtt.0.Tablet-Flur.screenSwitch: Hiermit kann im Beispiel der Bildschirm an- und abgeschaltet werden, gleichzeitig wird der Status aktualisiert, wenn anderweitig der Bildschirm an/abgeschaltet wird.
4. ...noch weiteres, das ich nach und nach ergänze...

Adapter-Installation:

1. ioBroker -> Admin -> Adapter
2. Installieren aus eigener URL
   
3. Benutzerdefiniert -> URL https://github.com/Acgua/ioBroker.fully-mqtt einfügen, mit "Installieren" bestätigen
4. Adapter sollte nun installiert werden und als "Fully Kiosk Browser (MQTT)" erscheinen. Nun eine Instanz hinzufügen.
5. Adapter-Einstellungen entsprechend vornehmen.

Einrichtung MQTT

1. In der Fully Browser App: Settings -> Other Settings -> MQTT Integration (PLUS)
   1. Enable MQTT -> einschalten
   2. MQTT Broker URL: mqtt://192.168.30.30:3000, dabei ist 192.168.30.30 die IP von ioBroker und 3000 der Port, den MQTT verwendet.
   3. MQTT Broker Username / Password: Kann man vergeben oder auch leer lassen. Wenn nicht gesetzt wird nur geprüft, dass die empfangenen Topics auch von Fully kommen und ob die IP von Fully mit der in den Adapter-Einstellungen übereinstimmt. Mit User/Passwort kann man halt noch zusätzlich absichern...
   4. MQTT Client ID: kann man leer lassen
   5. MQTT Device Info Topic und MQTT Event Topic: kann man Default so lassen, wertet der Adapter nicht weiter aus
2. In den Adapter-Einstellungen entsprechend bei "Use MQTT" des entsprechenden Tablets den Haken setzen und unter "MQTT Configuration" ggf. User, Passwort, sowie - wichtig - Port setzen - also selbe Port-Nummer wie in den Fully Browser App Settings (siehe oben).

Hinweise zum Testen

1. Am besten am Anfang den Adapter auf Debug stellen. Dann bekommt ihr mehr Infos. Keine Angst, das Log wird nicht alle paar ms gefüllt
2. Fehler/Probleme/Vorschläge gerne hier im Thread, oder - noch besser zusätzlich - als Github Issue unter https://github.com/Acgua/ioBroker.fully-mqtt/issues

So, ich hoffe ich habe nichts vergessen und würde mich sehr freuen, wenn ihr das ganze Testen könntet.
Auch bitte mal ohne MQTT testen, also in den Adapter-Einstellungen "Use MQTT" deaktivieren. Auch gerne bitte mit mehreren Tablets und unterschiedlichen Einstellungen testen.

Hi @newan

Vielen Dank für den Adapter, im Thread https://forum.iobroker.net/topic/64338/erledigt-adapter-für-aktienkurse-oder-gibt-es-bereits wurde ich darauf von Oli aufmerksam gemacht.

Ich habe einen ersten Test mit ein paar Symbolen gemacht und funktioniert sehr gut.

@oli
Cool, vielen Dank Oliver, den Adapter hatte ich nicht gefunden. Nach erstem Test funktioniert er so wie er soll.

@Alle - Somit hat sich diese Anfrage erledigt

@oliverio
Danke Oliver. Ich ergänze bei "Out of Scope" Daytrading und Echtzeitdaten

Hi,

ich bin gerade über diesen Thread gestolpert, bezüglich Suche nach Adapter für Börsenkurse.
Parser wird Seitenzugriff verweigert

Gibt es denn wirklich noch keinen Adapter für Aktienkurse, etc.?

Cooler Use Case wäre für mich z.B.: Ich lege eine Watchlist an, jew. etwa mit unterem Limit, und bekomme dann eine Email (alternativ Telegram), sobald der Tageskurs das erreicht.

@oliverio said in Parser wird Seitenzugriff verweigert:

Aber ein Skript oder Adapter würde ich trotzdem nicht entwickeln wollen.
So wie du auch geschrieben hast, in der nächsten Runde geht es dann darum,
was eine "technische Schutzmaßnahme" (Auswertung user agent id) ist.

Sinnvoll in einem Adapter wäre es wohl, eine offizielle API wie etwa von Alpha Vantage zu nutzen:

We are pleased to provide free stock API service for our global community of users for up to 5 API requests per minute and 500 requests per day. If you would like to target a larger API call volume, please visit premium membership.

Für AV gibt es auch Module, wie etwa https://github.com/zackurben/alphavantage
Müsste man sich halt näher ansehen.

Frage:
Besteht Interesse an einem Adapter? Oder gibt es das doch schon?

Ziel des Adapters wäre primär: Für in der Adapter-Konfiguration angelegte Wertpapiere werden die Kurse zuverlässig und regelmäßig in Datenpunkte geschrieben.
Ggf. noch optionaler Import historischer Kurse, sofern das die API sauber bietet.

Out of Scope:

• Komplexe Darstellungen und Auswertungen etc.
• Portfolio Management - dafür gibt es Tools wie etwa https://www.portfolio-performance.info/
• Daytrading und Echtzeitdaten

@ilovegym
@manfredhi

Sollte nun alles behoben sein. Sorry, hat etwas gedauert, konnte nicht früher.
Waren noch ein paar Fixes und Optimierungen notwendig, auch im Abfangen von Fehlern und Verbesserung von Logausgaben.

0.0.11 (2023-03-24)

• (Acgua) Fix: Remote admin password issue
• (Acgua) Improved debug and error log when sending REST API commands

Bitte testen, das Senden von Commands, wie etwa fully-mqtt.0.<Tablet>.Commands.loadStartURL sollte nun wieder sauber gehen. Es kommt auch bessere Logausgabe, wenn man falsches Remote-Admin-PW eingegeben hat (der Fully gibt da nur ein "Please login") zurück.

@manfredhi

Kannst du bitte Debug Log einschalten, und dann noch mal testen (Command loadStartUrl ausführen), und das komplette Log hier posten ab Adapter-Start.

@manfredhi
danke. Ich schau mir das morgen an.
Ggf. muss wohl noch weitere Debug-Logausgaben hinzufügen, um die Ursache zu finden, da es ja bei anderen, und bei mir, ja funktioniert.
Ich kann es aber ziemlich gut eingrenzen im Adapter Code.

@manfredhi
Was bekommst du denn als Ausgabe, wenn du im Browser folgendes eingibst:

http://x.x.x.x:2323/?cmd=loadStartURL&type=json&password=zzz

Dabei:

• x.x.x.x durch die IP-Adresse vom Fully Tablet ersetzen
• zzz durch dein Remote Admin Passwort ersetzen

@metaxa
danke
Ist behoben.

debug: fully-mqtt.0 Final Config: {"name":"123", ... "restPassword":"(hidden)", ...}

0.0.10 (2023-03-22)

• (Acgua) Do not show Remote Admin Password in debug log (#14)

@metaxa
freut mich, danke für deine Rückmeldung.

Achtung: Im Debug-Log wird in Zeile Final Config: ... das MQTT-Passwort ausgegeben. Oben auch in deinem Auszug. Bitte entfernen, falls du das nicht möchtest.
Ich habe mir hierfür ein Issue aufgemacht.
https://github.com/Acgua/ioBroker.fully-mqtt/issues/14

Acgua created this issue in Acgua/ioBroker.fully-mqtt

closed Debug Log shows the clear Remote Admin Password in "Final Config: ..." #14