peered - unpeered - ???

[betateilchen]

Bestimmt nur eine Kleinigkeit:

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

Der Weather Channel ist aber definitiv gepeered:

Code Auswählen Erweitern


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:


[martinp876]

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?

[strauch]

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

[martinp876]

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

[betateilchen]

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.

[martinp876]

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?

[betateilchen]

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

[betateilchen]

getestet, sieht ganz gut aus.


Aber einen hab ich noch:

Code Auswählen Erweitern

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.

[martinp876]

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?

[betateilchen]

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.

[martinp876]

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?

[betateilchen]

Das 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.

[martinp876]

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

[betateilchen]

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

[martinp876]

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

korrekt - ein gleitkommawert.

Im 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

Warum 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.

beim 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?

Code Auswählen Erweitern

{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)}

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

ja, das ist schade. Aber kein Problem, geht wie oben:

Code Auswählen Erweitern

{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)}

Die 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.

sub 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.

Ich 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