HM-TC-IT-WM-W-EU Wochenliste im Climate Channel

[martinp876]

könntest Du vielleicht darüber nachdenken, HMinfo komplett als Befehl in fhem einzubauen anstatt als Modul, das erst ein define braucht.

HMInfo wurde falsch genutzt - habe eine Antwort geschrieben.
Die Einschränkung hat aber nichts mit HM zu tun sondern mit Rudi, webCmd, set und get handling.

könntest Du vielleicht darüber nachdenken, HMinfo komplett als Befehl in fhem einzubauen anstatt als Modul, das erst ein define braucht.

eigentlich nicht.
- es gehört nicht in allgemeine Kommandos - bei weitem nicht jeder nutzt HM. Die wollen (mit recht) keine HM kommandos sehen.
- HMInfo repräsentiert eigentich eine Instanz "HM". Eine korrekte Architektur sollte ein "HM" istanziieren und auch ein frontend zu Verfügung stellen. FHEM hat hier den quick-and-dirty weg gewählt, dass dies implizit und ohne frontend (entity) gemacht wird. Dies aufzuräumen würde einige Probleme bereiten. HMInfo ist quasi einfach der weg, dies nachträglich zu machen. Es ist (wird) "quasi" die HM-Instanz.

Aber die Vorgehensweise über die myUtils hat sich etabliert

ja

und ist für Einsteiger am einfachsten zu verstehen

nein - man hat ihnen einfach nicht andere erklärt - bis jetzt.

Diese Vorgehensweise wirst Du nie wieder loswerden.

komplett nicht - muss ich auch nicht, es darf jeder rumsauen wie es ihm gefällt

Allerdings könnte man darüber diskutieren, ob die tempList überhaupt Konfigurationsdaten darstellt

sorry? Was den sonst? Alle Register sind daten, die das Device konfigurieren. Darüber lässt sich nun wirklich nicht streiten.

Ich brauch die tempList generell nicht - wozu auch, wenn ich fhem als Zentrale habe?

Frage der Philosophie - darüber streite ich definitiv nicht.

Aber die jetzt gewählte neue Benennung ist m.E. Lichtjahre davon entfernt, intuitiv oder gar anwenderfreundlich zu sein.

hm.
er sind Register "R_" ist gerechtfertigt.
Die Listen heissen P1 bis P3 - sollte in Ordnung gehen - gibt es alternativen?
die Nummer des Tages zum Sortieren... finde ich gut. Das könnte ein Streitpunkt sein - geschmackssache.

Was wäre intuitiv?

Gruss Martin

[betateilchen]

- es gehört nicht in allgemeine Kommandos - bei weitem nicht jeder nutzt HM. Die wollen (mit recht) keine HM kommandos sehen.
- HMInfo repräsentiert eigentich eine Instanz "HM". Eine korrekte Architektur sollte ein "HM" istanziieren und auch ein frontend zu Verfügung stellen.

Du hast noch nicht ganz verstanden, wie ich das mit der Implementierung des Befehls meine und wie das in fhem passiert. Genau DAS was Du da beschreibst, passiert nämlich, wenn Du HMinfo als eigenen Befehl implementierst. Jemand, der kein HM nutzt, wird den Befehl niemals zu Gesicht bekommen (er taucht nichtmal in der Hilfe auf!). Das zugehörige perl-Modul für den Befehl wird erst dann geladen, wenn hminfo zum ersten Mal benutzt wird. Du kannst das mit configdb testen: Den Befehl siehst Du nicht bei "help", aber Du kannst ihn trotzdem aufrufen, z.B. "configdb info" - danach steht er dann auch in help (bis zum nächsten fhem Start)

Register "R_" ist gerechtfertigt.
Die Listen heissen P1 bis P3 - sollte in Ordnung gehen - gibt es alternativen?
die Nummer des Tages zum Sortieren... finde ich gut.

Und wer maßt sich dabei an, festzulegen, ob der Wochenbeginn (0) nun am Sonntag oder Montag ist? Tagesnamen sind eindeutig, auch in ihrer Kurzform. Noch dazu, wo hier immer wieder Wert darauf gelegt wird, dass fhem auch international verwendet werden können muss (deshalb commandref in englisch Pflicht) und es durchaus viele Kulturkreise gibt, in denen der erste Tag der Woche eben nicht der Montag ist.

[TomWest]

Hi Martin,

habe es gerade getestet - und Funktioniert bei mir.
Du hast heute einen update gemacht?
Die Templisten heissen nun

R_P1_0_tempListSat

um eine Sortierung im web-frontend hin zu bekommen.

Ja, jetzt passt es. Nach einem clear readings auf dem Climate und danach clear readings auf dem Device und einem GetConfig auf dem Device ist nun alles, wie es soll! Vielen Dank! 

Im Web Frontend habe ich aber jetzt unter Set Climate immer noch TempListFri etc. kommt das noch von selbst?

Bis dann,
Thomas

[martinp876]

Es gibt kein separates Kommando für für die einzelnen Listen (p1,p2...) Das P123 ist ein Parameter im jeweiligen Kommando.

Es gibt mittlerweile ein
get cmdList
was eine "schnell-Hilfe" geben soll. da erhältst du die erwarteten Parameter zu einem Kommando

Code Auswählen Erweitern

tempListFri [prep|exec] [p1|p2|p3] HH:MM temp ...
tempListMon [prep|exec] [p1|p2|p3] HH:MM temp ...
tempListSat [prep|exec] [p1|p2|p3] HH:MM temp ...
tempListSun [prep|exec] [p1|p2|p3] HH:MM temp ...
tempListThu [prep|exec] [p1|p2|p3] HH:MM temp ...
tempListTue [prep|exec] [p1|p2|p3] HH:MM temp ...
tempListWed [prep|exec] [p1|p2|p3] HH:MM temp ...

war das die Frage oder habe ich es falsch verstanden?

Gruss Martin

[TomWest]

Hi Martin,

ja das war die Frage. Ein eigener Parameter ist ja auch sinnvoll, wieviele Kommandos würden es denn sonst werden.

Vielen Dank für die Hilfe, ich denke, das wäre es dann (im Moment ...  )

[martinp876]

eigentlich ist der Wochentag der erste Parameter... das Kommando ist tempList. 7 Kommandos sind nicht sinnvoll (aber historisch...)