Erfahrene
Hab den Adapter grün aber ich finde kein einziges Objekt das zuletzt genau zu dem Zeitpunkt aktualisiert worden ist, zu dem ich in der Tapo-App das letzte erkannte Ereignis sehe. Merkwürdig.
Ich bekomme allerdings Alarmmeldungen .. die gar nicht passieren dürften .. weil die Tür vor der Kamera zu ist .. und keiner im Raum.
@topsurfer
Man kann den 3EM problemlos lokal über MQTT im Shelly Adapter betreiben. Ich habe 2 Stück davon so im Einsatz. Ich nutze aber die Cloud gar nicht und habe diese auch noch nie genutzt.
Mir ist aber auch nicht bekannt, dass man die originale Shelly-App überhaupt ohne Cloud (also rein lokal) benutzen kann. Daher wundert mich das beschriebene „Problem“ ehrlich gesagt auch nicht. Es gibt sowohl für IOS als auch für Android lokal nutzbare Alternativen zur originalen Shelly App.
@topsurfer
für shelly gen 1 geräte eine zweite Instanz des shelly Adapters einrichten und auf Protocol COAP stellen. Wie steht in der ausführlichen Anleitung des Shelly Adapters.
Am shelly mqtt NICHT aktivieten dann ist dieser nirmal via cloud und gleichzeitig im iobroker etreichbar.
Typischrs Setup ist
1 Shelly Instanz mit COAP für gen 1 Geräte
1 Shelly Instanz mit MQTT für gen 2 ++ Getäte
Und warim die App bei Gen1 lokal auch nicjt geht wenn du mqtt aktivierst musst du shelly fragen.
@jb_sullivan
komisch. Das npm Paket ist im beta/latest repo und im stable repo ident.
Mach ein issue auf.
@wolfgang-gary Bei mir auch seit Monaten. Mir konnte da noch keiner helfen.
Kann das jemand hier entwickeln ???? oder gibt es das gar schon und ich bin nur zu blind ??
Das lässt sich mit einfachen Icons lösen. Ich kann das gern in meinem Icon-Adapter umsetzen. Du könntest dann ein Widget deiner Wahl nehmen und die Icons den Zuständen zuordnen.
Nachtrag: Das Ausblenden der Linie im Hintergrund ist nicht so einfach. Da müsstest du ein Widget mit einer flächicgen Füllung drüberlegen.
Z=0 deinen Grundriss
Z=1 eine farbige Fläsche in der Frabe des Hintergrunds
Z=2 ein Widget mit den Tür-Icons
Dann geht es!
@carsten04 sagte in vis-2-widgets-collection:
Wird allerdings noch etwas dauern...
Da das alles in der Freizeit passiert ist es selbstverständlich.
Man kann froh sein das du etwas in der Freizeit machts.
Mach mal bitte auf GitHub ein feature request auf ...
Habe ich gemacht, hoffentlich ist das richtig so.
War das erste mal. 
@nograx sagte in Test Adapter Zendure Solarflow:
- autoModel: 8 wird auch bei der HA Integration immer mit geschickt. Da das Zendure abgenickt hat (die Integration offiziell ist) muss ich davon ausgehen das das so OK ist.
wie Du möchtest.
Ob das speziell abgenickt wurde und bei vielen anderen Stellen: weiß ich nicht.
Meine Vermutung ist, dass sie nur auf Nachfrage reagieren und mal machen lassen.
Kostet sie nichts. Aber genug mit Spekulationen.
Für meinen Teil, mach ich so viel wie möglich safe.
packState: Kannst du das bitte erläutern und mir ein Beispiel zeigen? Kann zu "packState" in der HA Integration nicht viel finden.
"hart" schalten. Hier bräuchte ich auch mal ein Beispiel bzw. ne Referenz in dem Code der HA Integration, das verstehe ich nämlich auch nicht.
packSate habe ich dazu in meinem code zur Auswertung mit verwendet, weil es quasi "idle" ist und in HA das IDLE (State=0) ist.
Versteht man schon 
Im solarflow-adapter-code benutzt Du auch Idle für packState:0
Möchte mich jetzt nicht wieder Tage mit der HA-Intergration beschäftigen
Egal, war zu lang raus aus dem py-Code und musste das gerade nochmal runterladen und anschauen.
Basis nun: Zendure-HA-1.1.4-pre2
Wenn man in den Code schaut, wird es schnell nachvollziehbar 
A)
Was passiert bei Wechsel von negativ -> positiv (CHARGING → DISCHARGING)?
Beispiel: -100 W (Laden aus Netz) zu 200 W (Entladen ins Haus).
{
"autoModel": 8,
"autoModelProgram": 2,
"autoModelValue": {
"chargingPower": 0,
"outPower": 200,
"freq": 0
}
}
B)
sodele oder vice versa, was passiert bei Wechsel von positiv -> negativ (DISCHARGING → CHARGING)?
Beispiel: 200 W (Entladen) -> -100 W (Laden aus Netz).
{
"autoModel": 8,
"autoModelProgram": 1,
"autoModelValue": {
"chargingPower": 100,
"outPower": 0,
"chargingType": 1,
"price": 2
}
}
C)
Bedingung für IDLE (State=0)
IDLE wird immer dann gesetzt, wenn:
Der gewünschte neue Wert 0 ist
-> Payload mit autoModel=0.
Oder beim Umschalten der Richtung (negativ <-> positiv).
Damit wird garantiert, dass das Gerät nie „hart“ von Charge zu Discharge springt.
Im Code (z.B. hyper2000.py) :
"autoModel": 8 if state == ManagerState.DISCHARGING else 0,
"autoModelProgram": 2 if state == ManagerState.DISCHARGING else 0,
Wenn state == IDLE, landet man also automatisch bei 0/0.
Fazit:
Hinweis:
urprünglich ging ich davon aus, dass packState:0 == Idle ist und habe es in meinem Code entsprechend verwendet.
Wie bereits erwähnt, akzeptiert HA den Status auch als "IDLE", selbst wenn packState ≠ 0, solange andere Parameter passen.
Die Details lassen sich im Code auch gut nachvollziehen – ich denke, damit sollte genug Material da sein, um es weiterzuverfolgen.
Meine Analyse beschränkt sich auf die HA-Integration und zum Vergleich mit der solar-flow-Adapter-Funktion.
Fehler meinerseits sind dabei nicht ausgeschlossen.
Persönlich mag ich den Weg nicht, zu hacky und zu viele unbekannte Faktoren.
Bleibe beim bisherigen: Mode: 0, smartMode: 1 und outputLimit.
im HA code
Zendure-HA-1.1.4-pre2\custom_components\zendure_ha\manager.py
Zendure-HA-1.1.4-pre2\custom_components\zendure_ha\devices
Alle Geräte wie hub2000.py oder hyper2000.py etc.
Hoffe, das hilft Dir – mehr habe ich dazu nicht, gern geschehen.
Hallo ioBroker Freunde!
Wir haben ein neues Video für euch auf unserem YouTube-Kanal.
Link zu Video: https://youtu.be/FSDocYOAkSM
In diesem Video zeigen wir Schritt für Schritt, wie ihr mit ioBroker, dem neuen n8n-Adapter und einem KI-Agenten echte intelligente Automatisierung in eure Haussteuerung bringt.
Was genau wird umgesetzt?
Wir bauen gemeinsam einen kompletten Workflow, bei dem ihr über Telegram mit eurem Smart Home kommunizieren könnt.
Ein KI-Agent analysiert eure natürliche Sprache, versteht, was ihr meint, und wandelt den Text in konkrete Steuerbefehle um, die an ioBroker übergeben werden. Am Ende bekommt ihr direkt über Telegram eine Rückmeldung.
Der Workflow besteht aus:
Das Ziel:
Ein smarter Agent, der eure Sprache versteht und selbständig passende Aktionen im Smart Home auslöst, ohne dass ihr konkrete IDs oder Skripte kennen müsst.
Dieses Projekt versteht sich als Experiment und Einladung zum Mitmachen:
Nutzt es als Grundlage, um eigene Ideen umzusetzen, Prompts anzupassen und neue Wege der Hausautomation zu entdecken.
Video anschauen, ausprobieren, weiterentwickeln.
Hmmmm - in 0.6.0 Beta hatte ich keine Fehlermeldung. In 0.6.0 Stable kommt diese Meldung
discovergy.0
6588 2025-09-08 15:55:35.981 error State type : submeter unknown, send this information to the developer ==> submeter : false
