@schimi
Ja, die Funktion habe ich tatsächlich aktiviert. Ich habe nur angenommen, dass das Schalten des SG Ready Eingang 1 sich darüber hinwegsetzt und die forcierten Werte trotzdem erreicht.
Werde es mal ausprobieren... Danke

Hallo,

meine Rolläden fahren nach Himmelsrichtung, Außentemperatur und Lichtsensor. Jetzt aber ich auf der Südseite des Haues 4 Fenster, von denen zwei Fenster zu den Kinderzimmern gehören. Die Kinder machen Mittagsschlaf. Deswegen kann es sein, dass die Rolläden der Südseite ca. gegen 11:30 Uhr auf Sonnenschutz fahren. Wenn ich die Rolläden dann zum Mittagsschlaf der Kinder vollständig schließe, was passiert dann, wenn die Bedingungen für den Sonnenschutz während des Mittagsschlafs nicht mehr gegeben sind. Fahren dann alle Rolläden auf der Südseite hoch oder nur die, die noch im Sonnenschutzmodus sind?
Ich hoffe, ihr könnt mir folgen

ich hatte im Prinzip das gleiche Problem wie auch @wendy2702
Ich glaube, ich habe es beheben können... und zwar lag es bei mir daran, dass ich die Informationen unter dem Reiter "Schalten" nicht angegeben habe. Dem SHM fehlte schlicht und ergreifend die Info, wann die Geräte laufen. Da ich den Verbrauch bei mir über Homematic-Steckdosen messe, sehe ich nur die Möglichkeit, die Statuserkennung "vom Leistungswert" zu übernehmen. Die Steckdosen sind dauerhaft eingeschaltet, der Status der Homematic-Steckdose macht daher wenig Sinn. Bei mir wird gem. nachfolgender Abbildung der Status auf "ein" gesetzt, wenn der Verbrauch > 5 W ist.

@foxro
Vielen Dank!
Ich werde morgen mit einem der Kinderzimmer einen Test fahren und berichten.

@Bostil
Das Hochfahren der Rolläden zur vollen Stunde habe ich nicht. Ich habe allerdings auch nicht den Frostschutz aktiviert. Es könnte also tatsächlich daran liegen.

@simatec
Vielen Dank für das Script. Ich bin weiterhin noch am Ausprobieren. Ich habe den Rolladen Schlafzimmer inzwischen wieder so herstellen können, dass er heute Morgen per Taster hochgefahren wurde und heute Nachmittag in den Sonnenschutzmodus gegangen ist.
Ich kann leider nicht genau sagen, was ich geändert habe, weil es zu viel Herumprobieren war. Jedenfalls läuft er jetzt wieder, wie ich es mir vorstelle. Jetzt sind es nur noch die beiden Rolladen in den Kinderzimmern, die ich täglich morgens per Taster manuell hochfahre, die Sonnenschutzfunktion aber (noch) nicht wieder funktioniert. Interessant ist zu beobachten, dass wenn ich "autoall" ausführe, die Rolladen in den Kinderzimmern im "manumode" bleiben. Als würden die die Info gar nicht mitbekommen. Das hatte ich bei den Rolladen im Schlafzimmer auch noch vor ein paar Tagen.
Dein Script werde ich daher ein paar Tage zurückstellen.

Bei mir läuft es jetzt auch. Hatte vorher in der Handy-App für die Kamera unter Erweiterte Einstellungen ziemlich komplexe Benutzerdaten (Benutzername + Passwort) vergeben. Vielleicht wurden irgendwelche Sonderzeichen nicht erkannt. Interessant ist aber, dass ich die Daten im ioBroker Adapter anschließend nicht aktualisiert habe und es trotzdem funktionierte. Aber zuletzt sogar die Daten (siehe Abbildung unten) freigelassen und es funktioniert. Der Adapter greift also nur die Daten aus der Handy-App ab. Ich hatte das eigentlich anders verstanden, dass die Daten nur noch lokal im Netzwerk bleiben.

Nicht falsch verstehen... Danke für den Adapter.
Ich hatte mir nur vorgestellt, dass ich die Kamera anschließend rein lokal verwenden kann, weil ich nicht möchte, dass mein Kamerabild in irgendeiner Cloud zu sehen ist.
Aber ich habe da schon eine Idee, wie sich das realisieren lässt.

@walter-white said in Test Adapter TP-Link Tapo:

@christian-5

Seit wann habt ihr die Probleme?

Ich habe die Probleme seit wenigen Tagen, wobei ich den Adapter auch einige Tage deaktiviert hatte, weil die Kamera abgeschaltet war.
Daher kann ich nicht genau sagen, seit wann der Fehler wieder auftritt. Was ich allerdings sagen kann... ich habe bei mir die Auto Update Funktion deaktiviert. Ich habe weder die App noch die Kamera geupdatet.
Für meine Begriffe liegt der Fehler irgendwo darin, wenn der Adapter sich lokal auf die Kamera aufschalten möchte. Hatte ja schon meine Beobachtungen mit der Änderung der lokalen Benutzerdaten kundgetan.

@rintrium

Schön, dass du noch aktiv bist und der Adapter lebt...
Ich bin jetzt nicht der große Javascript Experte. Aber ich unterstütze gerne beim Testen oder Ähnlichem.

@bilbo
Installiere mal den shelly Adapter neu, danach hat es bei mir funktioniert. Hatte auch erst die ID geändert und dann zurück. Funktionierte nicht.

@android51
hatte die vorgenannte Fehlermeldung heute Morgen erneut. Weiterhin kann ich kein Fehlverhalten der Rolladen erkennen. Den Rolladen kann ich vermutlich über die Ziffer 8 zuordnen. Kann daraus aber nichts schließen.

Eigentlich läuft die Version weiterhin tadellos. Heute hatte ich allerdings folgende "error" Meldungen, wobei ich glaube, dass ich diese in der alten Version auch ab und zu mal hatte. Ich kann daraus auch kein Fehlverhalten der Rolladen erkennen.

2024-12-20 16:41:10.612 - error: selverf.0 (31105) Received fault code!
2024-12-20 16:41:10.616 - error: selverf.0 (31105) Response from gateway was: {"methodResponse":{"fault":[{"array":[{"string":["Syntax error!"],"int":["8"]}]}]}}

Kurze Zwischeninfo:
Bisher läuft die neue Version tadellos. Einige Testfahrten gestern liefen ohne Probleme und die heutigen (automatisierten) Rolladenfahrten ebenfalls.

@rintrium sagte in [Neuer Adapter] SelveRF:

@Android51 Danke fürs Angebot zum Testen, dann würde ich das doch direkt mal wahrnehmen

Danke für deinen Einsatz!
Ich habe jetzt auch auf 0.7.0 aktualisiert. Erste Tests waren erfolgreich. Ich werde weiter beobachten und berichten.

@rintrium

Schön, dass du noch aktiv bist und der Adapter lebt...
Ich bin jetzt nicht der große Javascript Experte. Aber ich unterstütze gerne beim Testen oder Ähnlichem.

Problem erkannt, Problem gebannt.
Es lag tatsächlich an dem Prozess der phoscon App (altes zigbee Gateway). Habe den Prozess gestern gestoppt und gestrige Testfahrten und auch heute Morgen verliefen wieder problemlos. Anscheinend hat der Prozess im Hintergrund noch auf den USB Port zugegriffen und den SelveRF Stick gestört ("busy").

@mcm1957
Widmen wir uns nun dem anscheinend größeren Problem, dass der selve-Adapter aktualisiert werden muss. Wer ist dazu in der Lage? Gibt es Co-Entwickler? Kann man irgendwie unterstützen?

sollten die Geräte, die über den SEMP-Adapter kommen, in der Geräteliste auftauchen? Bei mir tauchen sie nämlich nur unter der Verbraucherübersicht auf.

Iobroker, selve-rf und der zigbee2mqtt Server laufen alle auf einem raspberry pi 4.
Den selve-Adapter wie auch den zigbee Stick (sonoff) werden per serial id im iobroker Adapter (selve) und in der configuration.yaml (zigbee2mqtt) hinterlegt. Es ist also präzise vorgegeben, auf welchen Stick sie zugreifen sollen.
Ich habe heute morgen festgestellt, dass ich wieder die Fehlermeldung (selve Stick busy) hatte und manche Rolläden nicht fuhren. Der zigbee2mqtt Server war seit gestern gestoppt. Also liegt es doch noch an was anderem.
Das einzige, was mir noch einfällt... Ich habe die zuvor genutzte phoscon Instanz (ebenfalls zigbee - vorher war der Conbee2 Stick im Einsatz) lediglich gelöscht. Vielleicht muss ich den Prozess noch stoppen. Da bin ich mir nicht sicher, worauf dieser zugreift. Werde es heute Abend testen.

Ich habe inzwischen herausgefunden, woran es liegt. Ich kann den Fehler (Connection result error: Error: Error: Device or resource busy, cannot open /dev/serial/by-id/usb-FTDI_FT230X_Basic_UART_DM01F9AT-if00-port0) so lange reproduzieren, wie eben der zigbee2mqtt server läuft. Sobald ich diesen stoppe und den selve adapter neustarte, gibt es keine Fehlermeldung mehr. Wenn ich den zigbee2mqtt Server wieder aktiviere, kommt die Fehlermeldung durch den Selve-Adapter wieder.
Jetzt weiß ich zwar, woran es liegt, kann das Problem jedoch nicht beheben. Denn ich habe den zigbee2mqtt Server seit einer Woche im Einsatz und bin eigentlich begeistert und möchte ihn nicht mehr missen. Habt ihr eine Idee, wie ich das umgehen kann?
Ich sehe das Problem eigentlich nicht, man sagt dem Selve-Gateway und auch dem Zigbee-Gatway über /dev/serial/by-id genau, welchen USB-Port bzw. welches Endgerät verwendet werden soll. Warum ist das Selve-Gateway dann "busy"? Im 3. oder 4. Beitrag bestand wohl das gleiche Problem, nur halt mir einem Fhem-Server, statt zigbee2mqtt. Warum lässt sich der Selve-Adapter dadurch stören?