Das ist natürlich nicht so einfach zu lösen.
SF läuft ja über eine zyklische Abfrage aller definierten Devices, auch der Consumer Devices.

Um den Status asynchron arbeitender Consumerstatus "zeitnah" in SF darzustellen, müsste ich in einer Notify Funktion verarbeiten. Allerdings darf es nicht mit synchron arbeitender Consumer kollidieren, deren Status über die Schleife und quasi zeitgleich nochmal über eine Notify in SF verarbeitet werden.

Ich hoffe ich habe mich einigermaßen verständlich ausgedrückt.
Hmm ... nicht ganz trivial.

Zitat von: Damian am 25 September 2022, 16:59:09

Zitat von: schwatter am 25 September 2022, 15:48:32@Damian

Ok, Systemweit hat geholfen. Danke.
Noch eine Frage zur Card. Gibt es ein Autoresize für Card?
Gesetzt hab ich es so:

Code Auswählen Erweitern

card([PV_Deye1600_01:Power:col12],undef,[PV_Deye1600_01:Power] > 0 ? "sani_solar\@colorVal1":"fa_bolt\@colorVal2",0,1200,0,120,"Pv W",undef,"1,font-size:50%"," 130,,,,,,262")
Toll wäre es so:

Code Auswählen Erweitern

card([PV_Deye1600_01:Power:col12],undef,[PV_Deye1600_01:Power] > 0 ? "sani_solar\@colorVal1":"fa_bolt\@colorVal2",0,1200,0,120,"Pv W",undef,"1,font-size:50%"," 130,,,,,,[color=red]auto[/color]")
Wegen verschiedener Devices (Handy,Tablet,Pc,...)


Gruß schwatter

Für alle Cards gelten die gleichen Default-Werte - das ist beabsichtigt, damit das Erscheinungsbild bei mehreren Cards einheitlich bleibt. Eine Auto-Funktion würde dazu führen, dass die Skalierungen (Schriftgröße, Höhe, Breite, usw.) unterschiedliche wären.

Nabend,

wie wäre es, die Größe an das attr plotsize von FHEMWEB zu verknüpfen? Grund, ich habe Handy, Tablet und PC.
Das sieht dann bei dem gleichen Raum unschön aus. Leider oder auch zum Glück (liegt immer im Auge des Betrachters)
wird bei FHEMWEB vieles geteilt und jede Webinstanz schaut (relativ) identisch aus.
Momentan habe ich extra Räume dafür eingerichtet...

Oder für DOIF ein extra attr, in dem die Webinstanz mit Größe angegeben werden kann.
z.b "attr cardsize WEBphone:480,200 Webtablet:1024,480 Webpc:1900,500"

Gruß schwatter

Hallo
Auf meinem Test-Raspi VERSION  07.50.17

Alle drei Boxen unauffällig; keine ungewöhlichen Logmeldungen mit verbose 3 -> gänzlich keine Logeinträge 
Allerdings keine Kommandos etc. ausgeführt.

7590 7.51-105108 BETA wg. AVM Ticket; MeshMaster DSL aktiv
7490 7.29 MeshClient DSL inaktiv; Anschluss an externes Modem oder Router
7430 7.29 VPN Standalone DSL

Hi Heiko,

ja stimmt genau.
Beim nächsten Update von SF zieht es sich gerade.
Tuya arbeitet wohl asynchron.

Gestern hatte ich noch den Fehler gemacht SF in der Datail Ansicht zu schalten.
Heute in der Raumansicht ist das verhalten völlig klar.

Update von SF kommt zu früh, also vor dem on/off vom Tuya.
Mit dem nächsten Update von SF zieht es sich gerade.

Gruß,
Stefan

Falls einer danach sucht..es gibt eine Möglichkeit.
Im Charset des Displays nach einem Zeichen suchen was auch "leer" ist und das als Hex übergeben.

my $ww_tu = sprintf("%.0f",(ReadingsNum("DeltaSol_BX","Temp_Speicher_unten",0)));;
my $ww_tm = sprintf("%.0f",(ReadingsNum("DeltaSol_BX","Temp_Speicher_mitte",0)));;
my $ww_to = sprintf("%.0f",(ReadingsNum("DeltaSol_BX","Temp_Speicher_oben",0)));;
my $ww_pow = sprintf("%.0f",((ReadingsNum("VarWWepower","state",0) + ReadingsNum("DeltaSol_BX","Waermemenge.calc",0))));;
   ##$ww_pow = substr("\xFE\xFE\xFE\xFE\xFE".$ww_pow."W", -5);;
   $ww_pow = substr("\xA0\xA0\xA0\xA0\xA0".$ww_pow."W", -5);;
fhem ("set MQTT2_DVES_C04CC9 Row3 W: " . $ww_tu ."/".$ww_tm."/".$ww_to. "\xDFC " . $ww_pow);;


Ok jetzt habe ich eine Vermutung:

Im Event Monitor sehe ich folgende Reihenfolge beim Schalten:
2023-05-06 18:01:16 SolarForecast Forecast updated
2023-05-06 18:01:16 fhempy Stefan_Tablet_bf0572e0fb6ccbe356ykuh off

Also zuerst das Update vom Forecast, dann der Statuswechsel vom Tuya.

Drücke ich dann nochmal im Forecast UI auf den Knopf kommt noch ein
2023-05-06 18:01:33 SolarForecast Forecast updated
und der Status wird upgedated.

Das Update vom Forecast scheint zu früh zu kommen.

Liegt das daran das Tuya vielleicht erst den status umsetzt wenn der Schaltbefehl von der Steckdose bestätigt ist?

Muss ich mich an den Tuya Autor wenden oder wie gehe ich hier am besten vor?

Gruß und Danke,
Stefan

Hallo zusammen,

ich frage mal bei den Anfängern, weil ich wieder alles vergessen habe - wenn das hier falsch ist - bitte ins richtige Unterforum verschieben!

Hintergrund: Ich habe seit "vielen" Jahren eine FHEM-Installation - auf einem x86-Tablet mit Ubuntu, hatte "zuletzt" Ubuntu von 1406 auf 1606 gehoben, dabei die ganzen Perl-Module wegen Versionswechsel verloren, dadurch alle FHEM-Geräte wegen Nicht-Ansprechbarkeit automatisch gelöscht - naja, Wochen später ging dann das meiste irgendwie wieder und der User ts mag seitdem das System ungern endlich wieder updaten - noch dazu wo es kaum noch i386-Linuxe gibt.
Nun hatte ich selbstverständlich das FHEM auf automatischem Update und war der Meinung, dass das auch lief - und wie man die ganzen Tricks so programmiert, habe ich inzwischen natürlich weitgehend wieder vergessen - dont touch a running system.

Nun geht der Landroid-Mähroboter nach der Winterpause nicht mehr über FHEM auszulesen.
Habe gesucht und im Wiki gefunden:
1 - die haben das MQTT-System geändert - andere Server, andere Authentifikation und
2 - gibt jetzt landroidutils.pm und damit bequeme(re) Möglichkeiten.
Nur fehlt mir die Datei. Weil das Update nicht mehr läuft. Weil Update an sich nicht läuft, weil wohl System-SSL veraltet.

Konkret:
"update Check" liefert:

Downloading https://fhem.de/fhemupdate/controls_fhem.txt
https://fhem.de/fhemupdate/controls_fhem.txt: Can't connect(2) to https://fhem.de:443:  SSL connect attempt failed error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure

Das anderswo empfohlene Auskommentieren einer HTTPS-setzenden Zeile im 98_update.pm ändert irgendwie gar nix an dieser Fehlermeldung...

"version" liefert "Latest Revision: 22601...", neueste Filedaten etwa August 2020.

So. Da steh ich nun.
Wie bekomme ich mein FHEM möglichst ohne (sofortige) System-Reinstallation erstmal wieder auf einen einigermassen aktuellen Stand?
 - oder wenigstens die Worx-Landroid-Schnittstelle wieder zum Laufen (der Rest geht ja, warum anfassen)?

Und als Bonus: Gi...

Ok danke fürs schauen.
Das heißt für mich es sollte gehen.

Im Event Monitor sehe ich beim Schalten vom Tuya Device nur:
2023-05-06 17:19:23 fhempy tuya_local_bf0572e0fb6ccbe356ykuh on
2023-05-06 17:19:24 fhempy tuya_local_bf0572e0fb6ccbe356ykuh on

Und vom Forecast Device sehe ich:
2023-05-06 17:19:24 SolarForecast Forecast updated


Sind das die state events oder müsste da auch state stehen?
Habe auch mal
event-min-interval .*:300
event-on-change-reading .*
entfernt.

Hat aber leider auch nichts gebracht.

Dann habe ich einen Testdummy angelegt.
Der Testdummy schaltet und es updated in der Raum Übersicht.
Im EventMonitor sehe ich für den Testdummy:
2023-05-06 17:41:36 dummy testdummy on
2023-05-06 17:41:36 SolarForecast Forecast updated

Sieht gleich aus wie beim Tuya device.
Komisch warum updated es beim Tuya device nicht?

Also mit einem Dummy geht es mit dem Tuya Device nicht.
Das Tuya Device feuert im Event Monitor immer 2 mal im Gegensatz zum Dummy Device.
Events scheinen ok.

Was ich noch bemerkt habe, wenn ich mit dem Tuya device im Forecast in der Raum Übersicht schalte, schaltet das Tuya Device aber der Status ändert sich nicht in der Anzeige vom Forecast Device.
Drücke ich dann nochmal auf den Schalter der noch im alten Status hängt im Forecast Device ändert sich der Status auf den richtigen Wert. Also updated.
Habt ihr noch eine Idee?

Danke und Gruß,
Stefan

Das statefile wird nur automatisch geschrieben, wenn der Befehl "shutdown" ausgeführt wird. Egal, ob mit oder ohne restart.