FHEM Forum

Bestimmt nur eine Kleinigkeit:

(http://up.picr.de/17631795is.png)

Der Weather Channel ist aber definitiv gepeered:


Internals:
   CFGFN     
   DEF        23C77601
   HMUSB_MSGCNT 6
   HMUSB_RAWMSG E23C776,0000,096E1E3C,FF,FFC9,05861023C7760000000A80E8100018
   HMUSB_RSSI -55
   HMUSB_TIME 2014-03-12 19:50:22
   LASTInputDev HMUSB
   MSGCNT     6
   NAME       ku_RT_Weather
   NR         303
   STATE      ???
   TYPE       CUL_HM
   chanNo     01
   device     ku_RT
   peerList   ku_TC_Weather,
   CHANGETIME:
   Helper:
     Dblog:
       Measured-temp:
         Fhemdblog:
           TIME       1394650222.86061
           VALUE      23.2
   Readings:
     2014-03-12 18:46:23   R-sign          off
     2014-03-12 19:51:05   RegL_01:          08:00 00:00
     2014-03-12 19:50:22   measured-temp   23.2
     2014-03-12 19:51:05   peerList        ku_TC_Weather,
   Helper:
     peerIDsRaw ,261B9E01,00000000
     Role:
       chn        1
     Shadowreg:
Attributes:


ist das eine Frage?
RT weather wird mit TC-IT weather gepeert. Damit schaltet der RT seinen eigenen Fuehler ab und nutzt nuzt nur noch den des TC (oder eines anderen Fuehlerns)
Das peeren der Climate ist fuer das uebertragen der Solltemp verantwortlich. Man kann die beiden Dinge also trennen.
War das die Aussage?

Ich soll ja betateilchen nicht interpretieren ;-), aber ich glaube seine Frage ist warum steht da ??? und nicht peered.

ah!
nun - STATE gibt es je entity exact einmal. der Developer hat nun die Aufgabe zu entscheiden, was per default da drin stehen sollte. Die 3 Fragezeichen ist immer unschoen, also versuche ich den sinnvollsten Wert zu finden.

Device-only-entities (also wenn der channel eine eigene entity ist) haben protokoll also hauptaufgabe und erhalten entsprechend diesen Inhalt.
Channels bekommen das entsptechend ihrer Aufgabe. Das ist bei Sensoren einfach.
Weather des RT ist ein Sensor und sollte die measured-temp anzeigen - sehe gerade dass es noch nicht der Fall ist beim RT.

Channels die nur peerings verwalten (RT_Climate, RT_ClimaTeam) haben sollten in state 'peered/unpeered' stehen haben.

Channels die nach peering aktiv werden sollten 'unpeered' oder den eigenen Wert nach peering enthalten.

Das mit peered/unpeered ist neu und sicher noch nicht komplett

Zitat von: martinp876 am 13 März 2014, 09:59:50
Das mit peered/unpeered ist neu und sicher noch nicht komplett

Darauf wollte ich hinaus, und strauch hat meine Frage völlig exakt verstanden. Der Channel ist gepeered und es wäre hübscher, wenn dann auch "peered" da stehen würde. Nix weiter.

ok - habe ich mittlerweile kapiert.
Bei Weather Channel - wie beschrieben - sollte aber das Wetter im state stehen. So hab ich es jetzt auch geaendert.
wie angesprochen: peered/unpeered kommt nur in den State, wenn es kein naheliegendes primaer-reading gibt.

state T: 21.3 H: 52

ok soweit?

auch eine Lösung.  Kann ich mir aber erst nächste Woche anschauen, wenn ich wieder zu Hause bin.

getestet, sieht ganz gut aus.


Aber einen hab ich noch:

2014-03-18 18:26:55 CUL_HM ku_TC batteryLevel: 3

Da fehlt mal wieder eine Nachkommastelle, denn das würde als 3.0 um einiges schöner aussehen.

optik für einen Puristen wie dich, dem jede Einheit zu viel ist?
Bei der setTemp verstehe ich das, weil der Vergleich sonst nicht funktioniert im web-frontend.
Hier kostet so ein sprintf schon Performance. Bringt es etwas?

ja...

• Einheitlichkeit
• Bei temperature Readings werden die .0 Fälle auch korrekt dargestellt
• ein split auf einen nicht vorhandenen Punkt bringt jedesmal eine Fehlermeldung auf die Konsole.

Und mit der Frage ob Einheiten oder nicht, hat das überhaupt nichts zu tun, wir reden hier nur vom value.

hm - Einheitlichkeit - da müsste man einmal alles prüfen. Hoffentlich sind alle Prozent Werte mit einer Kommastelle versehen, die werden in 0.5er Schritten angegeben.

Bei den temp-readings ist es notwendig, weil Rudi einen String vergleicht um in den drop-down Listen den korrekten Wert zu erkennen. Da arbeitet er gelegentlich auch mit Text... also muss er es so machen.

Das mit den Parsen verstehe ich nicht - einen Wert zum Verarbeiten musst du nicht auf den '.' parsen oder spliten. Du könntest einfach den Wert als float verarbeiten (da stript dir Perl auch automatisch Einheiten). Aber mir muss nicht klar sein, was jeder im Einzelnen macht.

Was mit ein bisschen weh tut ist, dass in der Konsequenz an vielen Stellen ein sprintf genutzt werden muss - das kostet Performance.

Bevor ich also anfange aufzuräumen - wo ist es überall notwendig es "einheitlich" zu machen- und wie viele Stellen sind den das:
level
pct
batteryLevel
Prozent-werte in den Registern
Zeitwerte in den Registern (evtl 2 Nachkommastellen)
Brightness ... nein, der Wert wird (leider) nicht korrekt gewandelt. Müsste eigentlich Prozent sein.
windDirRange
windSpeed
rain
actuator
ValvePosition
energy
power 
voltage
frequency
....
Den Rest suche ich morgen....

Also (ernsthaft!) bevor ich anfange:
- um Werte mit Kommastellen als float zu verarbeiten muss man nicht auf einen '.' parsen. So man vor und Nachkommastellen getrennt braucht kann man dies lösen ohne Error-Meldung
- welche Werte müssen vereinheitlicht werden? Alle immer mit gleicher Anzahl Nachkommastellen?
- das ganze geht nicht kostenlos - es ist sicher machbar, aber es addiert definitiv Code und man verliert wieder ein bisschen Performance.
=> wann und welcher Wert muss so ausgerüstet werden?

Zitat von: martinp876 am 18 März 2014, 23:18:15Das mit den Parsen verstehe ich nicht - einen Wert zum Verarbeiten musst du nicht auf den '.' parsen oder spliten.

Was ich mit Deinen readings in meinen RSS Layouts (und an anderen Stellen) anstellen muss, um sie korrekt darstellen zu können, haben wir schon vor ein paar Monaten angefangen zu diskutieren, ohne dass Du es seinerzeit verstehen (geschweige denn einsehen) wolltest oder konntest.

Aber jetzt auch noch anzufangen, die notwendigen Zusatzarbeiten absichtlich dadurch zu erschweren, dass Du das gleiche Reading einmal als Wert mit Nachkommastellen und mal ohne zu liefern, finde ich völlig unnötig. Für Deine völlig wahllosen Homematic-Readings brauche ich jetzt schon eine Vielzahl von eigenen Funktionen, um sie verarbeiten zu können. Bitte denke bei solchen Dingen nicht immer nur an Deine Vorstellungen - wie oft haben wir darüber schon diskutiert?

Selbst Rudi hat seine Module schon länger so angepasst, dass Readings immer gleich formatiert (Nachkommastellen) ausgegeben werden, unabhängig davon, ob da .0 oder ein .x steht.

Sorry, das war eine ernsthafte Frage von mir - auch wenn ich immer nichts verstehe:

- die Werte sind nicht wahllos - es sind alles Readings die Nachkommastellen haben können und - wenn es keine gibt ohne '.' ausgegeben werden. Das ist Realität
- ich habe keine Ahnung, welche Werte du verarbeitest und ob du morgen mit dem Nächsten kommst. Wenn es notwendig ist immer die identische Anzahl Nachkommastellen liefern zu müssen kann ich das machen - das war eine ehrliche Frage.
- ich weiß nicht ob du mit einer flexibel Anzahl Vorkommastellen zurecht kommst
- warum du zum Werte verarbeiten für alles einen separaten Parser braucht muss ich sicher nicht verstehen. Die meisten programierer hätten meiner Erfahrung ach eine Funktion um float zu verarbeiten. Ich jedenfalls muss für dich somit einen separaten Parser für jeden Wert einbauen - und vorher die maximale Anzahl nachkommastellen definieren.
- Alle Anderen User bekommen das dann auch - mit oder ohne RSS feeds.
- dass ganze Zahlen kein Komma haben ist perl - ich schneide keins ab - aber das weißt du sicher. Das Dran-bauen ist exotisch, Aufwand und kostet Performance! Das macht man nicht ohne guten Grund!

Da wird eine Nachfrage wohl noch zulässig sein.

=> Also: welche Readings brauchen eine fixe Anzahl Nachkommastellen?
a) alle float
b) keine
c) besondere/Ausgewählte (bitte Liste angeben)

Ich kann es ehrlich nicht riechen, wo du es brauchst und wo nicht .... und wo es ein andrer brauche könnte, auch wenn du es hier brauchst.....

Gruss Martin

p.s.
wo liegt dein Code der vielen Formatierungen für HM? würde mich interessieren

Hallo Martin,

meine letzte Antwort war auch ernst und ehrlich geschrieben. Ich habe den Eindruck, Du machst grade mal alles wieder viel komplizierter als es ist. Eine typische Entwicklerkrankheit (unter der ich manchmal auch leider, aber in fhem stehe ich eher auf der Anwenderseite). Der battery Level ist nunmal ein Wert, der eine Nachkommastelle haben kann. Im Gegensatz zur ValvePos, wo es nur ganzzahlige Werte gibt.

Einfach gesagt: Überall da, wo Nachkommastellen im Value auftreten können, sollte die Nachkommastelle auch dann vorhanden sein, wenn sie zufälligerweise grade mal 0 ist. Warum das bei Temperaturen anstandslos gemacht wird und bei anderen Readings nicht, bleibt mir schleierhaft. Performancegründe lasse ich da nicht gelten.

Wofür ich das Splitten anhand des Punktes brauche, ist an einem Beispiel ganz einfach erklärt: Versuche doch mal, beim Generieren eines RSS innerhalb von fhem die Werte 1.4 11.5 und 23 am Dezimalpunkt ausgerichtet in das generierte jpg zu schreiben. Da kommst Du um einen Split am Punkt nicht rum, um die korrekte Position bestimmen zu können. Und es geht nicht nur um RSS.

Warum ich einen eigenen Parser für so viele Reading brauche, liegt einfach daran, dass jeder Entwickler bisher selbst entscheidet, ob er eine Einheit ins Reading schreibt oder nicht. Und dann auch noch unterschiedlich, z.B. bei Prozentwerten. Die kommen mit und ohne trennendes Leerzeichen vor - das weißt Du selbst doch am besten.

Es geht nicht darum, MIR einen Wunsch zu erfüllen, sondern um eine Grundsatzfrage. Dass Du die Nachkommastellen bei ganzzahligen Werten nicht abschneidest, ist mir völlig klar, das habe ich auch nirgends behauptet. Aber Du hast die Möglichkeit, die Nachkommastelle mit auszugeben, auch wenn sie 0 ist.

Ich kann die Anforderung mit den Nachkommastellen aber auch gerne in die gerade laufende Diskussion zum Thema Einheiten ja/nein/wie/warum einbringen - weiterhelfen tut mir das aber auch nicht.

Viele Grüße
Udo

ZitatDer battery Level ist nunmal ein Wert, der eine Nachkommastelle haben kann

korrekt - ein gleitkommawert.

ZitatIm Gegensatz zur ValvePos, wo es nur ganzzahlige Werte gibt.

ValvePos gibt es nicht
valvePos ist ein Kommando - gibt es als Reading nicht, war nicht auf meiner Liste
ValvePosition ist ein Interger/2 => es ist ein Gleitkommawert

ZitatWarum das bei Temperaturen anstandslos gemacht wird und bei anderen Readings nicht, bleibt mir schleierhaft.

weil Rudi in FHEMweb keine Datentypen kennt und (leider) strings vergleicht, um seine drop-drown liste bedienen zu können.

Zitatbeim Generieren eines RSS innerhalb von fhem die Werte 1.4 11.5 und 23 am Dezimalpunkt ausgerichtet in das generierte jpg zu schreiben

so in der Art?
{my $w = (s/(\d*.?\d*)/$1/,"1.4");;return sprintf("%08.4f",$w)}
{my $w = (s/(\d*.?\d*)/$1/,"11.5");;return sprintf("%08.4f",$w)}
{my $w = (s/(\d*.?\d*)/$1/,"23");;return sprintf("%08.4f",$w)}

Zitatdass jeder Entwickler bisher selbst entscheidet, ob er eine Einheit ins Reading schreibt oder nicht

ja, das ist schade. Aber kein Problem, geht wie oben:
{my $w = (s/(\d*.?\d*)/$1/,"1.4%");;return sprintf("%08.4f",$w)}
{my $w = (s/(\d*.?\d*)/$1/,"11.5 W");;return sprintf("%08.4f",$w)}
{my $w = (s/(\d*.?\d*)/$1/,"23 Celsius");;return sprintf("%08.4f",$w)}

ZitatDie kommen mit und ohne trennendes Leerzeichen vor

siehe Konverter Funktion oben. Vollkommen egal.

das sollte eigentich alles formatieren und stripen. Solange das Reading mit einer Zahl beginnt. Einheiten und Leerzeichen sind vollkommen egal. Wegen der Formatierung ist es etwas aufwändig.

Zitatsub getValFormated($$$){
  #inData = data from ReadingVal
  #intLen = length of decimals
  #fractLen = of fraction
  #fixed = 0: only minimum length, 1:fixed length, fill with 0
  my ($inData,$intLen,$fractLen,$fixed) = @_;
  $inData =~ s/([+-]?\d*.?\d*).*/$1/;
  my $formatString = ($fixed?0:"").($intLen+$fractLen).".".$fractLen;
  return sprintf("%${formatString}f",$inData);
}

so etwas hätte ich mir von Rudi vorgestellt, als ReadingsNum. ok, ohne Formatierung.... aber das entfernen der Einheiten ist ein Kinderspiel. Man sollte es unerfahrenen Usern zu Verfügung stellen! Das wer mein Gedanke bei der Einheiten Diskussion. Jetzt will man die akademische Lösung und wird Probleme haben, dass die Entwickler nachziehen.... wir werden sehen.

ZitatIch kann die Anforderung mit den Nachkommastellen aber auch gerne in die gerade laufende Diskussion zum Thema Einheiten ja/nein/wie/warum einbringen

wenn das allgemein gefordert ist solltest du dies unbedingt!

Gruss Martin

Hallo betateilchen,

ich hätte mir eine Antwort erwartet: ist die Methode zur Behandlung von Readings ok? Es ist natürlich nur ein Vorschlag nach 5 min nachdenken. Man kann x Varianten bereitstellen, die gleich das Reading lesen,... Die Frage ist, ob es deine Probleme ausreichend adressiert.

Gruss Martin

Du provozierst wirklich eine Antwort? Gestern habe ich sie mir bewußt verkniffen. Aber wenn Du sie unbedingt haben willst, bitteschön:

Du hast offenbar noch nie im Leben selbst (beispielsweise) mit einem RSS in fhem gearbeitet, sonst würdest Du so einen Scheiß solch einen abstrusen Vorschlag wie in Deinem gestrigen Beitrag nicht hier hinschreiben. Deine Vorschläge haben nichts damit zu tun, Zahlenwerte untereinander am Dezimalpunkt korrekt ausrichten zu können. Da gehört etwas mehr dazu. Ich müsste Deine Readings also erstmal regexen, dann sprintf() um sie anschließende wieder am danach vorhandenen Punkt splitten zu können, damit ich eine korrekte Positionierung innerhalb der generierten Grafik ermitteln kann. Gehts noch?

Hey, die Welt in fhem ist durchaus etwas größer als "nur" Homematic.

Und der RSS ist - wie bereits oben geschrieben - nur EIN Beispiel, wo diese nicht einheitliche Darstellung von Dezimalwerten Probleme (und anderen Leuten eine Menge Arbeit) macht. Und mal wieder ein ein vermeidbarer Anwenderhorror, den es nur in Homematic gibt und mit dem nur Du als Entwickler ein Problem hast, weil Dir die Anwendersicht aus der Praxis völlig da vorbeigeht, wo Hoeneß seine Ohren hat.


Du hattest gefragt  ;)

ja, hatte ich.
Leider hast du mir nciht gesagt, wo ich deinen Code finden kann.... schade.

Übrigens erwartest du, dass ich so etwas (sprintf) immer und für alle mache, damit du es nicht machen musst. Unter uns - am Ende macht es immer der Prozessor - egal wo. Gaspart ist da nichts - nur der Ort ändert sich. Oder was glaubst du, wo ein fixer dezimalpunkt sonst her kommen kann?
Wenn ich es macht wird es für alle Werte gemacht... auch wenn es keiner braucht. Nicht jeder braucht alles für RSS feeds aufbereitet, nur manche. Schlussendlich kostet es insgesamt mehr Performance.

Somit hinkt deine Rechnung schon etwas, meinst du nicht?

Im Übrigen kann ich garnicht sehen, warum du so viele readings unterschiedlich parsen musst... es geht mit einer einzigen Prozedur, wie ich gezeigt habe - für wirklich ALLE readings. Widerlegt hast du das nicht - nur genörgelt und behauptet. Fakten wären besser!

Bebauptungen : "Du hast ja keine Ahnung, deshalb zeige ich dir mein Problem auch nicht" kann ich nichts entgegensetzen, die sind selbst beantwortend.

Wie ich gelernt habe meckerst du gerne rum, ich baue etwas für dich ein (autoReadReg Abschaltung mit einem Knopf) was ich nun immer an vielen Stellen für dich mitziehe... und dann interessiert es dich nicht, du schaltest autoReadReg sogar ein.... Manchmal ein bisschen viel heisse Luft, fixe Meinungen (leider nicht immer durchdacht) von einem einzigen Standpunkt. Etwas Gehalt anstatt deftige Sprüche wären manchmal hilfreicher.

Es könnte viel einfacher sein....


Mich interessiert deine Meinung und Fakten, nicht deine Spruche.

Zitat von: martinp876 am 20 März 2014, 15:44:13und dann interessiert es dich nicht, du schaltest autoReadReg sogar ein

Fakt ist, dass auch diese pauschale Aussage so nicht richtig ist.

Mach was Du willst. Wie bisher auch. Ich habe als Anwender die Diskussion gegen Deine einbetonierten Entwickleransichten langsam auch satt. Bisher musste ich schon soviel Mist gradeziehen, da kommt es auf ein paar Dezimalstellen auch nicht mehr an.

dito.
sehr anstrengend - sehr egoistisch. Du scheinst "der Anwender" zu sein, da du immer in dieser Form von dir redest. Deine Probleme sind die aller Anwender, trauen sich aber nicht, etwas zusagen... auch eine Einstellung.

immer noch kein sample deines berühmten, komplexen RSS feed - schade