Ich habe das Modul Twilight um die Funktionalität von Loredos sunpos erweitert, und will es in zwei Wochen einchecken.
Hier stelle ich es zum Test bereit, um sicherzustellen, dass noch alle alten Funktionen wie vorher arbeiten.
Es wurde inhaltlich vieles verändert, so dass ein Test notwendig ist.
Zu den bekannten Readings sind folgende hinzugekommen:
Azimuth 309.6 2013-07-24 21:50:10
CompassPoint west-northwest 2013-07-24 21:50:10
Elevation -4.68 2013-07-24 21:50:10
Twilight 40.6 2013-07-24 21:50:10
condition 28 2013-07-24 20:20:10
condition_txt Mostly Cloudy 2013-07-24 20:20:10
horizon 0 2013-07-24 21:20:10
Ich würde gern im state einen anderen Wert als den verwendeten anzeigen.
Ich glaube nicht, dass jemand mit dem aktuellem state etwas anfangen kann - bitte Rückmeldungen was sinnvoller sein könnte, dann starte ich eine Abstimmung.
Loredo hätte jedenfalls gern den
CompassPoint.
Es gibt hier sogar hier ein Icon dafür.
Als Anhang das Modul und eine Dokumentation im html-Format.
Über Feedback wäre ich sehr erfreut.
hallo dietmar,
direkt zwei kommentare als feedback bevor ich es getestet habe:
wenn du in dem modul das reading state setzt und STATE nicht anfasst kann sich jeder STATE mit stateFormat anpassen und man könnte den bisherigen default lassen und jemand der die sonnenstands icons verwenden möchte könnte es einfach anpassen.
würde etwas dagegen sprechen die vier neuen readings auch klein zu schreiben ?
gruss
andre
Hallo Dietmar,
auch ich würde Andre hier beipflichten und den State nur über das state-Reading durch die readingFn's zu setzen, so kann der User über das stateFormat Attribut selber entscheiden, wie der state aussehen soll.
Ansonsten sieht es schonmal gut aus, hab aber explizit jetzt nicht diese Version aus diesem Thread getestet, sonder deine Vorab-Version. Konntest du das Problem beim speichern der fhem.cfg lösen?
Viele Grüße
Markus
Zitatwürde etwas dagegen sprechen die vier neuen readings auch klein zu schreiben ?
nein - kann ich ändern. Ist das eine Art Standard, oder gefällt es dir einfach besser?
ZitatKonntest du das Problem beim speichern der fhem.cfg lösen?
ja.
ja es gefällt mir besser. und wenn es einheitlich ist erst recht. aber deshalb hätte ich es nicht gesagt.
wegen dem kleinschreiben findest du hier etwas: http://www.fhemwiki.de/wiki/DevelopmentGuidelines#Bezeichnungen (//www.fhemwiki.de/wiki/DevelopmentGuidelines#Bezeichnungen)
gruss
andre
auf Kleinbuchstaben geändert:
(siehe Anhang / see attachement)
Sind sonst jemandem Merkwürdigkeiten aufgefallen?
Beim speichern stürzt er jedenfalls nicht mehr ab. Ansonsten funktioniert es tadellos :-)
Na, das höhrt sich ja ganz gut an.
Ich lasse es noch ein wenig weiter mitlaufen - dann werde ich es Anfang nächste Woche einchecken.
So viele Tester habe ich nicht gefunden - man kann in der Übersicht erkennen, dass es bisher nur 4 Downloads gab.
Das muss nix heisen. Der potenzielle Rest kann auch im Urlaub sein. Bei mir läuft deine Version jedenfalls Super.
Hallo Dietmar,
in der Doku ist mir noch aufgefallen, dass du offenbar das Grad Symbol ° als direktes Symbol verwendest.
(siehe Anhang / see attachement)
Währe super wenn du das in ° ändern könntest.
Vielen Dank
Gruß
Markus
Hallo Dietma,
nachdem ich deine Datei kopiert habe und dann in fhem reload 59_Twilight.pm ausgeführt habe, ist im Logfile folgender Eintrag:
2013.08.02 17:20:46 1: reload: Error:Modul 59_Twilight deactivated:
Type of arg 1 to keys must be hash or array (not hash element) at ./FHEM/59_Twilight.pm line 166, near "}) "
Type of arg 1 to keys must be hash or array (not hash element) at ./FHEM/59_Twilight.pm line 348, near "})"
Mir sagt das erstmal nichts.
Außerdem scheint sich mein FHEM dadurch immer zu beenden und ich muss es manuel über Telnet neu starten.
Nach dem Austauschen deiner Datei mit der alten Datei funktioniert alles wieder.
Gruß
Christian
Habe eine Kleinigkeit geändert - deine Perlversion scheint etwas strenger zu sein.
Die Doku habe ich angepasst!
Besten Dank Dietmar,
jetzt läuft es.
Nun muss ich nur meine Notifys ändern und dann kann ja sunpos raus.
Gruß
Christian
Ich habe jetzt auch seit einer guten Woche sunPos durch die Twilight Beta ersetzt. Scheint korrekt zu laufen.
:-)
Hallo Dietmar,
habe eben folgende Werte in Twilight entdeckt:
(siehe Anhang / see attachement)
(siehe Anhang / see attachement)
Müsste nicht eigentlich Light 6 sein und State auch?
Es gibt keine Wetterkorrektur.
Und das nächste Event soll auch sr_weather sein. Erstmal müsste aber der Untergang kommen.
Und was bedeuten die Readings mit "_el" hinten dran?
Gruß Christian
Es ist richtig, dass light nicht den richtigen Wert hat.
State und light stimmen aber grundsätzlich nicht überein.
Wenn ich es richtig sehe, wird sr_weather(morgens) nicht ausgeführt.
Warum werde ich prüfen.
In der alten Version von TW wurde der weather-horizon alle 900 Sekunden aktualisiert.
In dieser Version erfolgt die Aktualisierung nur noch dreimal am Tag: Um Mitternacht, eine Stunde vor sr_weather und eine Stunde vor ss_weather.
Damit möchte ich den kostenlosen Service von yahoo entlasten. Im letzen Jahr wurde der Google-Wetter-Service eingestellt. Vermutlich weil zuviele automatische Spider diesen Service genutzt haben.
Die Readings mit _el am Ende stammen aus einem Test meinerseits, bei dem ich feststellen wollte, ob die von TW ausgerechneten Werte sich von den Werten aus sunrise_el unterscheiden.
In der Version, die ich freigebe werden diese Readings nicht enthalten sein.
habe eine Idee, wie es passiert ist.
Werde etwas ändern und mehrere Tage prüfen, ob noch alles funktioniert.
ok,
super Dietmar.
Wenn ich in einer Form behilflich sein kann, gib Bescheid.
Gruß
Christian
neue Version eingecheckt - Doku erweitert.
Bei Problemen bitte hier melden.
Super Arbeit, vielen Dank.
Gruß
Markus
Was ich noch sagen wollte:
Im Moment werden standardmäßig folgende Zeilen wg. Debugging ausgegeben:
2013.08.15 19:42:00 3: [Twilight] sr_weather state=6 light=6 nextEvent=ss_weather 15.08.2013 20:42:19 deg=+0.0°
2013.08.15 19:42:00 3: [Twilight] sr_indoor state=5 light=5 nextEvent=sr_weather 15.08.2013 06:06:52 deg=+0.0°
2013.08.15 19:42:00 3: [Twilight] sr state=4 light=4 nextEvent=sr_indoor 15.08.2013 06:06:52 deg=+0.0°
2013.08.15 19:42:00 3: [Twilight] sr_civil state=3 light=3 nextEvent=sr 15.08.2013 06:06:52 deg=-6.0°
2013.08.15 19:42:00 3: [Twilight] sr_naut state=2 light=2 nextEvent=sr_civil 15.08.2013 05:22:01 deg=-12.0°
2013.08.15 19:41:59 3: [Twilight] sr_astro state=1 light=1 nextEvent=sr_naut 15.08.2013 04:31:42 deg=-18.0°
Eine kurze Frage, für die Berechnung des Sonnenstandes verwendest du die Attribute latitude und longtitude von "global". Wieso benutzt du denn nicht die selben Angaben aus den Definitionsargumenten die ja ohnehin verpflichtend sind um Twilight zu definieren?
Also:
$hash->{LATITUDE}
$hash->{LONGITUDE}
Viele Grüße
Markus
Ich habe den Code von Loredo einfach übernommen und nicht näher angesehen.
Wenn das stimmt, sollten wir das demnächst ändern.
Hallo Dietmar,
bei mir startet FHEM mit der neuen Version von Twilight nicht. Auf der Konsole erhalte ich folgende Fehlermeldung:
Use of uninitialized value in subtraction (-) at /usr/local/FHEM/share/fhem/FHEM/59_Twilight.pm line 532.
Undefined subroutine &main::Twilight_GetUpdate called at /usr/local/FHEM/share/fhem/FHEM/59_Twilight.pm line 88.
Währ super, wenn du das beheben kannst.
Vielen Dank
Gruß
Markus
Sobald ich ein Twilight Device aufrufe, stürzt Fhem auf FRITZ!box 7390 und Raspberry Pi ab.
Das hängt mit den genannten Fehlermeldung von mir zusammen.
Gruß
Markus
Komisch. Obwohl ich noch gar nicht auf die SVN Version aktualisiert habe, bekomme ich jetzt auch einen Fehler:
Undefined subroutine &main::Twilight_GetUpdate called at ./FHEM/59_Twilight.pm line 90.
... und FHEM stürzt ab :-(
Nach einem Update auf die SVN Version scheint alles wieder zu laufen (bei mir).
Jetzt kommen wir der Sache näher. Der Fehler tritt auf, wenn man die Detailseite des definierten Twilight Objekts aufrufen möchte.
Hängt damit zusammen, dass FHEMWEB beim Aufruf der Detailseite ein "get <Twilight-Device> ?" macht um die Usage zu erhalten und diesen FHEMWEB entsprechend darzustellen. Und in Twilight_Get() wird Twilight_GetUpdate($hash); direkt am anfang ausgeführt. Diese Funktion existiert allerdings nicht mehr.
Viele Grüße
Markus
hast du den Fehler immer noch? Bei mir kommt er nicht!
@Dietmar: hast du auch die aktuellste Version von FHEM im vollen Umfang im Einsatz?
Nein 5.4 älterer Stand.
Ich habe keinen Bedarf immer gleich das Neueste zu haben.
Ich schließe aus deiner Frage, dass dort das Problem zu suchen ist.
Nicht direkt. Führ mal bei dir ein "get <Twilight Device> ?" aus. Dabei stürzt FHEM dann ab mit der Meldung:
Undefined subroutine &main::Twilight_GetUpdate called at ./FHEM/59_Twilight.pm line 90.
Und in der Tat gibt es die Funktion Twilight_GetUpdate in Twilight nicht.
Viele Grüße
Markus
Sehe ich mir an
- bug in Twilight_Get repaired
- longitude and latitude now taken from TW definition
- $hash->{WEATHER_HORIZON} initialized
TW eingecheckt!
Zitat von: Dietmar63- longitude and latitude now taken from TW definition
Nur mal interessehalber: wo hast Du die Daten vorher hergenommen?
Diese Daten sind doch als globales Attribut in fhem vorhanden, von dort verwende ich sie z.B. in meinen Wettermodulen.
Heute morgen wurden die globalen Werte genutzt.
TW selbst wird mit latitude und longitude definiert.
Dann macht es, wie Markus bemerkt hat nicht unbedingt Sinn, die globalen Werte(wie sunrise_el) zu nutzen.
So kann man mehre TW mit unterschiedlichen latitude und longitude definieren - wenn es sein soll.
ok, verstanden, macht Sinn.
Irgendwann sollte sich wirklich mal jemand hinsetzen und ein 01_GEO.pm schreiben, wo der ganze ortsbezogene Kram (Koordinaten, sunrise, twilight, isday, holiday use) in einer einzigen Instanz abgefackelt wird. Der Vorschlag wurde ja schonmal irgendwo andiskutiert, aber leider nicht weiter verfolgt.
> So kann man mehre TW mit unterschiedlichen latitude und longitude definieren - wenn es sein soll.
Und SUNRISE_EL wird demnaechst auch diesen weg gehen (auch um "get sr sunrise" realisieren zu koennen), und die globale Variable kann dann entfernt werden. openweathermap muss dann nachziehen...
Was dagegen spricht ist die Moeglichkeit automatisch die Koordinaten anhand der IP-Addresse zu initialisieren. Aber vielleicht haben manche was gegen solche "Schnueffelei".
Zitat von: rudolfkoenig schrieb am Sa, 17 August 2013 08:00openweathermap muss dann nachziehen...
Als neulich die altitude als globales Attribut ergänzt wurde, habe ich openweathermap umgestrickt, um die Daten nicht mehr lokal pflegen zu müssen. Weißt Du eigentlich, was Du willst?
Ausserdem betrifft es nicht nur openweathermap, sondern zum Beispiel auch den I2C-Drucksensor.
Zitat von: rudolfkoenig schrieb am Sa, 17 August 2013 08:00und die globale Variable kann dann entfernt werden.
Es macht doch absolut keinen Sinn, in x-Modulen die identischen Parameter definieren zu müssen.
Alternativer Lösungsvorschlag: Die Attribute global existieren lassen und verwenden, solange das Attribut im definierten Device nicht existiert. Das wäre m.E. ein sehr viel flexiblerer Weg.
Hallo Dietmar,
Zitat von: Dietmar63 am 06 August 2013, 19:28:00
Die Readings mit _el am Ende stammen aus einem Test meinerseits, bei dem ich feststellen wollte, ob die von TW ausgerechneten Werte sich von den Werten aus sunrise_el unterscheiden.
In der Version, die ich freigebe werden diese Readings nicht enthalten sein.
ich habe in meinem Twilight-Modul immer noch Readings vom August stehen, die die Endung "_el" haben.
Wie werde ich die wieder los, damit nur noch die aktuellen übrig bleiben?
Gruß
Reimer
Zitat von: wing350 am 31 Oktober 2013, 17:28:51
ich habe in meinem Twilight-Modul immer noch Readings vom August stehen, die die Endung "_el" haben.
Wie werde ich die wieder los, damit nur noch die aktuellen übrig bleiben?
Fhem ist ja sooo berechenbar ;) ... schau mal hier: http://fhem.de/commandref.html#deletereading
Gruß, Peter
die neueste Modulversion herunterladen und fhem mal mit "shutdown restart" durchstarten.
Hallo Dietmar,
habe dein Modul getestet und für super befunden.
Zusätzlich habe ich auch noch einen Sensor der die Solare Einstrahlung (http://www.fhemwiki.de/wiki/1-Wire_Umweltsensor) misst. Mit anderen Worten: wieviel Sonne scheint zurZeit. Das kann dein Modul ja logischerweise nicht leisten.
Könnte man das Modul so erweitern, das aus einem externen Reading die Solare Einstrahlung herangezogen wird um somit ein besseres und fein granualareres LIGHT-Reading zu erhalten?
melde mich morgen dazu
Das geht auf jeden Fall. Wie stellst du dir das vor.
TW ermittelt heute schon mehrere Werte aus denen eine"virtuelle" Helligkeit ermittelt wird: light(1-6), twilight(0-100) und twilight_weather(0-100). Alle diese Wert werden nur berechnet aus dem Sonnenstand und dem Wetter.
Ich könnte ein Attribut einführen, in dem man den Namen des Device und das Reading ablegen kann. Mit diesem Wert könnte ich dann neue TW-Readings erzeugen oder die obigen anders berechnen. Sunpos wird eh alle 5 Minuten neu errechnet, dann könnte man auch das fremde Reading abfragen.
Was schwebt Dir so vor?
Das hört sich ja sehr interessant an, dann könnte man z.B. readings aus Openweathermap mit einberechnen um Wind- und Lichtwerte aus der eigenen oder nahe liegenden Stationen zu nutzen um Twilight noch genauer zu gestalten oder zu erweitern, wäre das denn möglich?
Ja, möglich ist vieles. Es nur fraglich, ob es dann allgemein verständlich bleibt.
Man müsste einerseits das zu verwendende Reading und eventuell sogar die Formel für den Helligkeitswert in TW parametrisierbar machen. Dann kann alles mit TW gemacht werden.
War von meiner Seite eher eine rein hypothetische Frage, könnte aber für Eigenheim Besitzer, die ihre Energie über Fotovoltaik-, Windkraft- oder Solaranlagen selber erzeugen, schon interessant werden in Zukunft ...
Hallo,
Zitatkönnte aber für Eigenheim Besitzer,
Diese brauchen eine Vort-Ort_Wetterstation die die Wettergegebenheiten vor Ort messen und sich nicht auf eine Wettervorhersage verlassen.
Grüße
repair of some minor seldom bugs, and a new algorithm to calulate the twilights. The results are now calulated by SUNRISE_EL
Hi Dietmar,
scheinbar bringt das letzte Update FHEM dazu nicht mehr zu starten ;)
Habe heute mal seit längerem ein Update gemacht und erhalte folgende Meldungen nach dem shutdown restart im Log und FHEM startet nicht weiter, das Modul aus dem Backup hat hier abhilfe geschaffen.
Prototype mismatch: sub main::Twilight_calc ($$$$$$$) vs ($$) at ./FHEM/59_Twilight.pm line 219, <$fh> line 894.
Undefined subroutine &main::timelocal_nocheck called at ./FHEM/59_Twilight.pm line 199, <$fh> line 894.
Greetz
Eldrik
Hallo,
auch ich kann FHEM nach dem Einspielen des Twilight-Updates nicht mehr starten.
Ich habe die alte Datei wieder zurückgespielt, das Update scheint fehlerhaft zu sein !
gefixt und eingecheckt
Hallo,
ich habe auch ein Problem seit dem update. Fhem startet nicht mehr.
Nach dem starten von fhem bekomme ich im Raspbian folgende Fehlermeldung:
Prototype mismatch: sub main::Twilight_calc ($$$$$$$) vs ($$) at ./FHEM/59_Twilight.pm line 219, <$fh> line 365.
Undefined subroutine &main::timelocal_nocheck called at ./FHEM/59_Twilight.pm line 199, <$fh> line 365.
Update wiederholen, eventuell 59_Twilight.pm vorher löschen
Klappt wieder,
habe gerade das Update neu aufgespielt und es funktioniert wieder alles.
Danke!
Geht wieder, vielen Dank
Hallo,
mir ist aufgefallen dass zusätzlich zu der Zeit das Datum bei nextEventTime angezeigt wird.
Da die Abstände der Ereignisse niemals länger als 24 Stunden auseinander liegen, empfinde ich das nicht gerade als Verbesserung.
wenn das nächste Ereignis um 21:00 Uhr stattfindet dann sicher am selben Tag, niemals 2Tage später! Das gleiche ist bei 6:00 Uhr morgens,
es wird sicher das "nächste 6:00 Uhr" sein, das Datum ist also ersichtlich total überflüssig!
Da ich mir in FHEM die Uhrzeit des nächsten Ereignisses anzeigen lasse, stört das Datum jetzt gewaltig, weil die Tabelle dadurch unnötig
vergrößert wird.
Ein Tipp wäre schön, wie ich das Datum in der Anzeige wieder weg bekomme.
Gruß
Tom
Ich baue das gleich zurück. Die Änderung war nicht beabsichtigt und ist nicht notwendig.
Unsere FHEM Freunde jenseits des Polarkreises würden Dir bei dieser Aussage nicht zustimmen, aber die Zielgruppe ist eher vernachlässigbar. ;-)
ausgebaut und eingcheckt. Steht morgen früh zur Verfügung oder aus SVN selbst herausholen.
Zitat von: volschin am 14 Juni 2015, 14:17:03
Unsere FHEM Freunde jenseits des Polarkreises würden Dir bei dieser Aussage nicht zustimmen, aber die Zielgruppe ist eher vernachlässigbar. ;-)
In einem solchen Fall kann TW nicht wirklich den nächsten Zeitpunkt berechen.