Hallo zusammen.
In meinem System gibt es ein Problem mit der Updatefunktion per Dropdown-Befehl.
Anscheinend passiert nicht das, was vorgesehen ist. Die local_version-Nummer ändert sich nicht.
Auch mit shutdown restore nicht.
Bislang habe ich das immer händisch erledigt, nach diesem Post:
https://forum.fhem.de/index.php?topic=138502.msg1315095#msg1315095
1) Konfiguration (unter ./opt/fhem/conf/) sichern bzw. umbenennen (z.B. myapp_config.fhemapp.json nach myapp_config_save.fhemapp.json)
2) FHEMAPP Device in FHEM löschen (z.B. delete myapp)
3) FHEMApp (unter ./opt/fhem/www/) löschen (z.B. den Ordner fhemapp4 inkl. aller Unterverzeichnisse)
4) FHEMAPP Device in FHEM neu erstellen (z.B. define myapp fhemapp fhemapp4)
5) Installation/Update für FHEMApp ausführen (z.B. set myapp update)
6) Konfiguration (unter ./opt/fhem/conf/) wiederherstellen (z.B. myapp_config_save.fhemapp.json nach myapp_config.fhemapp.json umbenennen)
Das klappt auch, mit dem entsprechenden Aufwand.
defmod myapp FHEMAPP fhemapp4
attr myapp room FhemApp
setstate myapp defined
setstate myapp 2025-02-05 22:04:22 .latest_tarball_url https://api.github.com/repos/jemu75/fhemApp/tarball/v4.8.1
setstate myapp 2025-02-05 22:04:22 .latest_url https://api.github.com/repos/jemu75/fhemApp/releases
setstate myapp 2025-02-05 22:16:49 .local_version_src CHANGELOG.md
setstate myapp 2025-02-05 23:09:37 configLastRead Wed Feb 5 23:09:37 2025
setstate myapp 2025-02-05 22:04:22 latest_html_url https://github.com/jemu75/fhemApp/releases/tag/v4.8.1
setstate myapp 2025-02-05 23:10:39 latest_info ## Button
\
- Bugfix for popout command
\
## iFrame
\
- Bugfix for width on Resizing
setstate myapp 2025-02-05 22:04:22 latest_published_at 2025-01-19T09:21:51Z
setstate myapp 2025-02-05 22:04:22 latest_tag_name v4.8.1
setstate myapp 2025-02-05 22:34:57 local_version v4.8.1
setstate myapp 2025-02-06 15:10:41 next_cycle Thu Feb 6 16:10:41 2025
setstate myapp 2025-02-05 22:04:22 request_result success
setstate myapp 2025-02-05 23:09:37 state defined
setstate myapp 2025-02-05 22:34:57 update_available 0Vielleicht kann mir jemand einen Hinweis geben, wo es klemmen könnte.
Btw, weiss jemand eine Erklärung für fhem-log-Einträge dieser Art?:
sethostname: Verwenden Sie "Netzwerk" in der Systemsteuerung zum Festlegen
des Hostnamens. Der Befehl Hostname -s wird nicht unterst�tzt.Datum / Uhrzeit wird nicht geloged, Anzahl ist riesig, in 15 Stunden über 5500 mal.
Gruß in die Runde und vielen Dank
Ulli
Vielleicht (!) liegt es daran, dass der update-Server nicht so antwortet, wie erwartet. Hatte dadurch die letzten paar Tage ein paar unmotivierte restarts, gepatchte Version hier: https://forum.fhem.de/index.php?msg=1332983
Damit konnte ich zumindest die FHEMApp-Version auf v4.8.1 hochziehen (war vorher älter), ohne dass irgendwas schlimmeres passiert zu sein scheint...
@Beta-User
Danke dir.
Hab's mal "eingebaut", momentan gibbet nix an Updates zum testen.
Die seltsamen fhem-log-Einträge kommen weiterhin, habe noch keine Idee dazu...
Ist das eine Win.*-Box, auf der FHEM läuft?
Hallo in die Runde,
ich habe die update-Funktion eben nochmal getestet. Bei mir läuft alles einwandfrei. @ulli_r weshalb machst du die updates bisher eigentlich manuell?
Bezüglich der Fehler die aus dem FHEMAPP.pm Modul kommen, bin ich leider auf Benni angewiesen. Er hatte diesen Part damals in FHEM implementiert und ich hatte die App erstellt.
Grüße
Jens :)
@Beta-User
In der Tat, reale win10 Hardware.
@ jemu75
Hi Jens.
Nur so komm ich in den Genuß der aktuellen Versionen.
Update per Dropdown bewirkt anscheinend nichts, die local_version
bleibt danach, auch nach shutdown restart, gleich.
Ich habe die gepatche 02_FHEMApp mal "eingebaut", beim nächsten Update
kann ich das testen.
Gruß von mir...
Das mit "Hostname" kommt m.E. nicht (direkt) aus dem Modul - evtl. einfach machen, was die sw-Schleuder aus Redmond vorschlägt?
@Beta-User
wahrscheinlich hast du Recht, nicht aus dem Modul.
Ansonsten, der PC hat einen definierten Hostname.
Merkwürdig ist halt, dass die Einträge ins log keinen
Zeitstempel haben.
Bleibt die Frage, von wo innerhalb von fhem resp. PERL
da zugegriffen wird.
Hi zusammen,
ich kann euch leider auch nicht sagen, wie es zu diesen Log-Meldungen kommt.
Die gehören schon irgendwie zum FHEMAPP-Modul. Das scheint auf den ersten Blick das Setzen der Readings wiederzuspiegeln.
@ulli_r: Hast du irgendwas, was auf die myapp-Events triggert?
gb#
@ Benni
Hi Benni.
ZitatHast du irgendwas, was auf die myapp-Events triggert?
Ich denke nein, nix gezielt angelegt.
Habe mal die FHEMapp-config stillgelegt und ne neue fhem.log schreiben lassen,
die cruden Meldungen laufen weiterhin auf.
Für's Modul im Eventmonitor mit Filter keine Events, zum testen hab ich mal ein paar
attribs angelegt und gelöscht, diese Events waren erwartungsgemäß zu sehen.
Habe auch ne reine Textsuche über den fhem-Ordner gemacht mit Hostname -s. Keine Funde.
Mit Hostname einige Funde, z.B. im Ordner assets "index-ep882Ot9.js".
Ich glaube hostname lässt garkeine Parameter zu.
Also, weiter forschen...
Gruß
Ulli
Ich wird daran liegen, dass Windows gewisse Befehle nicht unterstützt.
Zitat von: marvin78 am 07 Februar 2025, 07:49:45Ich wird daran liegen, dass Windows gewisse Befehle nicht unterstützt.
Davon gehe ich auch aus.
Im Moment würde ich (wegen der Fehlermeldungen) auf Shelly tippen oder eines der TV-Module. Das sind jedenfalls ein paar der wenigen Module, in denen "hostname()"-Aufrufe drin sind. Die dürften dann Perl-intern auf den unbekannten Code umgeleitet werden.
@ulli_r:
Da Win10 eh demnächst "tot" ist, solltest du darüber nachdenken, ob das ganze nicht besser auf einem Linux aufgehoben wäre. Derartige Effekte sind leider immer dann zu beobachten, wenn Win.* im Spiel ist. FHEM unter Win wird so selten verwendet, dass man sowas eigentlich guten Gewissens nur Leuten empfehlen kann, die solche Meldungen dann auch debuggen können und patches liefern.
UU. liegt das mit dem update auch daran, dass intern Download/Auspack-Befehle verwendet werden sollen, die unter Win auch nicht (ohne weiteres) laufem...
@Beta-User
Erst mal vielen Dank für die Unterstützung.
Mit win10 hast du tatsächlich recht. Inzwischen habe ich auch erkannt,
dass ich mich wohl um Linux nicht mehr herumdrücken sollte.
Fhem läuft bei mir im Hintergrund seit etlichen Jahren mit, um Geräte
die von den ELV-Transreceivern nicht verarbeitet werden, dennoch im
Contronics-Frontend nutzbar zu machen.
Das ganze System ist seit mehr als 20 Jahren "gewachsen", auf
ca. 350 Datenpunkte. Da sich bei Contronics firmenmäßig
einiges verändert hat, anscheinend nicht positiv, bin ich motiviert fhem
zum primären System zu migrieren.
Daher, zunächst mehr als Versuch gedacht, auf dem
gleichen Rechner wie die CL-Studio Software.
ZitatIm Moment würde ich (wegen der Fehlermeldungen) auf Shelly tippen oder eines der TV-Module.
Shelly ist mir bei den Forschungen auch irgendwo aufgefallen. Es sind 4 Shelly-Devices in Betrieb
(auch MQTT), wovon 2 uni's ein Ladegerät managen (Spannung, Strom, Zeit, Ein/Aus) und 2 Plugs plus Tiefkühlung und EDV.
Werde mal versuchen alles was mit shelly in Zusammenhang steht schrittweise zu entfernen. Mal sehen was für Effekte entstehen.
TV-Module sind nicht in Gebauch, vermutlich rufen die dann auch nicht ins Netzwerk.
@FHEMapp-Team
Danke. Das ist genau nach meinem Geschmack. :)
Gruß in die Runde
Ulli
Hmm, MQTT sollte nicht dass Problem sein; gemeint war das "direkte" Shelly-Modul. Ggf. die mal löschen und dann schauen, ob die Log-Einträge weg sind.
So ist mein Plan ;)
@Beta-User
Stand der Forschung:
- Habe das aktuelle 36_Shelly.pm dem Zugriff entzogen.
- Neue fhem.log anlegen lassen.
- Starten.
- Keine "Hostname"-Einträge im log.
- Dieses 36_Shelly.pm 24222 2021-04-11 17:27:47Z implantiert. Readout adc(voltage) shellyuni hinzugefügt
- neu starten.
- shellies funktionieren.
- Keine "Hostname"-Einträge im log.
Möglicherweise tritt die Meldung ab der Version 6.02 Beta3 auf.
Ich habe nicht alle publizierten Versionen zum vergleichen/testen zur Verfügung,
also nur spekulativ.
Vielen Dank für die Unterstützung
Gruß in die Runde
Ulli
Bitte diese Sache an @Starkstrombastler (im Shelly-Thread) melden.
Zitat von: Beta-User am 07 Februar 2025, 14:13:35gemeint war das "direkte" Shelly-Modul. Ggf. die mal löschen und dann schauen, ob die Log-Einträge weg sind.
Oh je, hier hat ja "hostname" gewaltig Wellen geschlagen.
In 36_Shelly.pm wird tatsächlich mehrfach "hostname" genutzt und es gab auch ähnliche Fehlerberichte. Daraufhin wurde im Shelly-Modul das
Attribut "host_ip" eingeführt, um den Problemen bei Non-Linux-Systemen aus dem Weg zu gehen.
Hmmm, vielleicht beim Initialisieren das OS prüfen und dann das Attribut auf "irgendwas" setzen?
Afair macht das OS-Checken auch fhem.pl irgendwo, vielleicht kann man "abkupfern"?
Die riesige Anzahl an (eigentlich) unzuordenbaren Einträgen im logfile ist halt "äußerst unschön";
Zitat von: Beta-User am 09 Februar 2025, 19:06:50Hmmm, vielleicht beim Initialisieren das OS prüfen und dann das Attribut auf "irgendwas" setzen?
Beim Define wird bereits geprüft ob "hostname" etwas brauchbares liefert, und wenn nicht wird das Attribut "host_ip" auf "xxx.xxx.xxx.xxx" gesetzt. Eine Meldung dazu wird ins Log geschrieben.
@Ulli: Bitte einmal ein Shelly-Device (mit der aktuellen Version) anlegen und checken, ob das Attribut mit dem Fake-Eintrag angelegt wird.
@Starkstrombastler, @Beta-User
Sorry, bin verspätet, Auszeit wg. Schicksalsschlag.
Daher nun kurz:
- Komplett-Update fhem
- Umbenennen fhem.log
- host_ip bei 2x Uni & 2x plug s eingetragen
- keine hostname-Eintäge im neuen log
PERFEKT
Vielen Dank
MfG
Ulli
Ulli, herzliches Beileid, was auch immer passiert ist.
Grüße
Bernhard
@Starkstrombastler
Hallo Bernhard,
danke für die Anteilnahme.
Kurze Rückmeldung zu "hostname" & "host_ip":
Ich hatte 2 shelly uni übersehen, entsprechend sehen die log's aus.
uni's gelöscht, neu angelegt, alles gut, auch im log.
"host_ip" auf "xxx.xxx.xxx.xxx".
Vielen Dank.
Gruß
btw: für die shelly uni's gibt es anscheinend kein MQTT-Template, oder?
Ulli