Moin,
im alternativen fronthem-Repository (https://github.com/wvhn/fronthem) habe ich mal etwas Ordnung in die Versionen gebracht. Im master branch sind jetzt folgende Versionen verfügbar:
- v1.0 / v1.0.1:
erste Version nach dem Zusammentragen aller wichtigen Änderungen aus dem Forum und verschiedenen Forks
also im wesentlichen die Version, die viele sich über längere Zeit nach Lektüre der Themen im Forum selbst zusammenkopiert haben
- v1.1:
Erweiterung der Zeitangaben für Plots (durations) auf alle von smartVISU unterstützten Modi
Diese Version war jetzt ca. 2 1/2 Jahre im master branch und sollte gut getestet sein.
- Neu v1.2:
- Erweiterung des UZSU-Steuerobjekts um sunrise/sunset aus fhem, sowie keinere Verbesserungen zur Vermeidung von Fehlermeldungen (Danke an raman)
- Websocket Port und maximal zulässige Länge von Nachrichten können jetzt konfiguriert werden (Neustart fhem erforderlich) (Danke ebenfalls an raman)
Diese beiden Features waren bisher im develop branch und sollten ausreichend getestet sein.
- Der neue "JSON"-Konverter ermöglicht Übertragung von JSON-Objekten. Diese benötigt man z.B. für das Widget status.activelist.
Im develop branch sind aktuell noch zwei zusätzliche Features:
- die Ausführung der UZSU-Funktion ohne notify in fhem sowie die automatische Befüllung des device strings (wieder Dank an raman)
Beides sehe ich als breaking change, da Anwender ihre notifies löschen und die device strings ändern müssen, um Fehlfunktionen zu vermeiden.
Wenn das hier von der Mehrheit akzeptiert wird, kann ich die Änderung gerne in den master branch nehmen.
- die Erweiterung der Auswertemöglichkeiten für Plots durch Definition weiterer SQL-Abfragen ist klasse - Danke an alkazaa.
Der Code ist gut kommentiert und erklärt den Einsatz der zusätzlichen Parametrierungsmöglichkeiten.
Die Erweiterungen funktionieren in fronthem gut, verwenden aber einzelne Parameter anders, als smartVISU dies vorsieht. Ich muss mir bei Gelegenheit nochmal genauer ansehen, wie ich das unter einen Hut bringe - auch mit Rücksicht auf die anderen Backends.
Für Tests und Feedback bin ich dankbar!
Gruß
Wolfram
EDIT: ich habe den JSON-Konverter in "JSONdata" umbenannt, um Konflikte mit sonstigen JSON-Routinen zu vermeiden. Dies ist nun in beiden branches verfügbar (tag v1.2 im master branch erneuert).
Hallo Wolfram,
hatte mal wieder ein wenig Zeit und habe diese Meldung gesehen.
Wenn ich ein
update force https://raw.githubusercontent.com/wvhn/fronthem/master/controls_fronthem.txtmache bekomme ich die Meldung:
2026.02.23 19:15:49.751 1: Downloading https://raw.githubusercontent.com/wvhn/fronthem/master/controls_fronthem.txt
2026.02.23 19:15:50.079 1: UPD FHEM/01_fronthem.pm
2026.02.23 19:15:50.194 1: Got 29329 bytes for FHEM/01_fronthem.pm, expected 30263
2026.02.23 19:15:50.195 1: aborting.
Hast du einen Tip?
Danke
Michael
Sorry an alle, die am Update via FHEM gescheitert sind. Das war ein Anfängerfehler.
Die Update-Prozedur erlaubt nur LF am Zeilenende bzw. ignoriert die CR bei CRLF. Dann stimmen natürlich die Größenangaben in der controls_fronthem.txt nicht. ???
Das ist jetzt gefixt und die neue Version heißt v1.2.0
Gruß
Wolfram
Hi Wolfram,
kein Problem, ich finde es klasse wie du dich hier einbringst!
Und über das Problem mit dem CR bzw. CRLF ist wohl schon so mancher Programmierer gestolpert
Das update läuft jetzt auf Anhieb durch!
Danke
Michael
Hallo Wolfram,
damit auch die FHEM Nutzer davon etwas mitbekommen habe ich den Beitrag aus dem KNX Forum hier eingefügt.
Hat sich alles erledigt, hatte die "neuen" Dateien aus dem Master Branch übernommen :-[ :-[ ::) :-*
Mit dem Develop funktioniert wieder alles wie gehabt.... Sorry,ich lass das mal stehen vieleicht passiert das jemand anders auch...
Eigenlich nutze ich die UZSU intensiv mit Smartvisu unter FHEM, ändere aber selten etwas an den Schaltzeiten. Lediglich wenn die Sonne wieder länger am Himmel steht nutze ich dies um die Rollos tags über herunterzufahren. Habe mich dann sehr gewundert das die Rollos nicht herunterfahren.... war aber nicht so tragisch da es im Moment eh sehr kühl ist.
Jetzt hatte ich ein wenig Zeit und bin auf Fehlersuche gegangen und die folgende Meldung in der LOG Datei gefunden:
delete wdt_uzsu_EG_EsseckeMitteBlind.* : Please define wdt_uzsu_EG_EsseckeMitteBlind.* first
Die Zeiten werden in FHEM nicht übernommen.
Konnte mich dann dunkel erinnern, das ich dieses Thema vor langer Zeit schon mal hatte. Das lag damals an dieser Zeile:
sub UZSU_execute($$;$)
{
my ($device, $uzsu, $save) = @_;
$uzsu = decode_json($uzsu);
fhem('delete wdt_uzsu_'.$device.'.*');
Ich habe sogar noch die alte 99_fronthemUtils gefunden, dort wurde das so gemacht:
$save = (defined($save) ? $save : "na");
my $rg = AttrVal('rg_uzsu_'.$device, "room", "na");
fhem('delete wdt_uzsu_'.$device.'.*') if($rg ne "na");
fhem('delete rg_uzsu_'.$device) if($rg ne "na");
## $uzsu = fronthem_decodejson($uzsu);
$uzsu = decode_json($uzsu);
Ich habe das bei mir so erweitert und es funktioniert.
Jetzt werden die Zeiten wieder in FHEM eingetragen, allerdings wird die Meldung
delete wdt_uzsu_EG_EsseckeMitteBlind.* : Please define wdt_uzsu_EG_EsseckeMitteBlind.* first
weiterhin in der LOG Datei ausgegeben. Der Eintrag in FHEM hat die Bezeichnung "wdt_uzsu_EG_EsseckeMitteBlind_0"
Kann das bitte jemand überprüfen.
Das UZSU Symbol blinkt allerdings auch aufgeregt vor sich hin....
Und ich hatte den "set level" string vergessen. Setze ich den noch ein wird die Fehlermeldung ein wenig länger:
ERROR evaluating my $EVENT= $evalSpecials->{'%EVENT'};my $EVTPART0= $evalSpecials->{'%EVTPART0'};my $EVTPART1= $evalSpecials->{'%EVTPART1'};my $EVTPART2= $evalSpecials->{'%EVTPART2'};my $EVTPART3= $evalSpecials->{'%EVTPART3'};my @MATCHED=@{$evalSpecials->{'%MATCHED'}};my $NAME= $evalSpecials->{'%NAME'};my $SELF= $evalSpecials->{'%SELF'};my $TYPE= $evalSpecials->{'%TYPE'};{ UZSU_execute($NAME, $EVTPART1) }: unexpected end of string while parsing JSON string, at character offset 149 (before "(end of string)") at ./FHEM/99_fronthemUtils.pm line 189.
UZSU return value: unexpected end of string while parsing JSON string, at character offset 149 (before "(end of string)") at ./FHEM/99_fronthemUtils.pm line 189.
und die Zeiten werden wieder nicht in FHEM eingetragen.
Das wird dann wohl wieder dieses Thema sein:
https://forum.fhem.de/index.php?topic=127432.45
Grüße
Michael
Danke Michael für die Auflösung.
Mir ist hier wichtig für alle Mitleser klarzustellen, dass die Version im master branch weiterhin so funktioniert, wie eh und je.
Wer die weniger getestete, aber für Neuanlagen komfortablere develop-Version verwendet, muss Anpassungen vornehmen, die dann aber nicht zur Master-Version kompatibel sind. Das meinte ich oben mit ,,breaking change".
Gruß
Wolfram