Das wäre die logische Erklärung. Wenn der Eltako immer nur Werte ohne Kommastelle ermittelt, würde dies zu unseren Werten im homee passen.
Die Werte. 18 und 25kmh hatte ich auch noch nicht beobachtet. Meine 17 habe ich nur im Wochen Diagramm gesehen und dies wird ja berechnet aus mehrern Einzelmessungen(Nehme ich an)
@Thomas: Danke für Deine Erläuterung 
Auf Ebene des EEP-Profils erfolgt bereits eine “Normierung” in 0…70m/s und das EEP-Profil gibt nur ganzzahlig 1, 2, 3, … 69, 70 m/s aus !?! 
Das ist ja ein Ding (und ein Graus für jeden Automatisierungstechniker, wenn auf diese Weise die 4-fach genauere Rohdaten-Auflösung des Sensors “vernichtet” wird…) 
Somit ist natürlich ein umgehender Freispruch des kleinen homee 
fällig, er möge mir bitte meinen Verdacht nachsehen 
- da kann er ja gar nicht anders, als die Windgeschwindigkeit in Sprüngen/Stufen von je 3,6 km/h anzuzeigen…
Mea culpa, kleiner homee 
Halt halt halt. Ich hab vermutet, dass dort nur ganzzahlige Werte ausgegeben werden. Mehr als eine Vermutung ist das nicht. Zwar eine die das Verhalten erklären würde, aber eben nur eine Vermutung.
Auszug aus der Beschreibung zum FWS61 EEP: A5-13-01
TT ist die Windstärke, sie liegt zwischen 0m/s (entspr. 0) und 70m/s (255)
Bsp: 0x55 = 85; 85*70/255 = 23 m/s
Das heißt doch das die gesendeten Werte noch mit dem Faktor 70/255 multipliziert werden müssen, um erstmal auf m/s zu kommen und dann mit dem Faktor 3,6 multipliziert um auf km/h
Dann wären es für den Wert 85 wie oben beim Bsp. 84km/h.
Die Auflösung des Sensors liegt dann doch eigentlich bei ca. 1,2 km/h-Schritten.
Hallo Harry,
gut, dass Du das in der Beschreibung nochmal nachgeschlagen hast, Danke!
Ich selbst habe den Sensor nicht, wollte ihn mir aber in nächster Zeit anschaffen, insbes. wegen der Kombination mit der Regen-Erkennung, deshalb auch mein reges Interesse an dieser Stelle.
Dein in den Eltako-Beschreibungen gefundener „Faktor 70/255“ entspricht ja meinem oben geposteten Wert 0,2745m/s pro Bit und bildet bei 1 Byte (1 Byte = 0…255) die Umrechnung des max. Wertes 70m/s auf 1 Bit Auflösung ab.
Allerdings sehe ich Deine km/h-Auflösung (1,2) nicht - ich komme auf 0,9882km/h pro Bit.
Wenn über das EEP-Profil nun evtl. doch Werte von 0…255 als Sensorwert ausgegeben werden (und nicht wie von CA derzeit angenommen 0…70 als m/s), dann wäre es nach meinem Verständnis jetzt wieder so wie zuvor vermutet: der kleine homee muss die Formel in seinem Hausaufgabenheft nochmal prüfen, die Berechnung müsste dann nicht -wie von Thomas in der Software recherchiert-
Beispiel 1:
Beispiel 2:
Beispiel 3 (siehe Eltako-Beispiel):
Das wäre dann wieder unser (zunächst vermuteter) Fehler von ca. 3,x .
Weiteres Indiz wäre auch, dass Eltako im Berechnungs-Beispiel den Wert 85 einsetzt, den dürte es ja bei max. 70m/s gar nicht geben:
Vielleicht kann da Thomas dem kleinen homee nochmal über die Schulter schauen 
.
@Thomas: Bitte nicht als Kritik, Besserwisserei oder Rechthaberei auffassen, sondern als konstruktiven Beitrag um einen evtl. noch an Eurem/unserem homee-System vorhandenen Bug gemeinsam zu finden und fixen.
Gruß
SmartHomer
Mal eine andere Frage. Warum wird eigentlich in km/h umgerechnet. Das ist beim Popp Z-Weather auch der Fall?! Ein jedem anderem Gataway wird die Windgeschwindigkeit in m/s angegeben.
Ich kann nur von mir selbst ausgehen: Ein Wert in km/h ist für mich “greifbarer/vorstellbarer” als ein Wert in m/s.
Auch zB in den Wetter-Vorhersagen wird die Windstärke (“heftige Böen/Sturm/Windgeschwindigkeiten bis zu 100 Stundenkilometer…”) genannt.
Das Wetter-Widget in homee gibt übrigens ebenfalls km/h an.
Aus meiner Sicht ist das schon gut so, dass homee auf km/h umrechnet.
Und: den (meintlichen?) Umrechnungs-Fehler hätten wir ja auch bei einer Angabe in m/s.
In den Telegrammen steht natürlich ein Wert von 0–255. So funktioniert EnOcean. Hier muss also auf 0–70 skaliert werden. Dies geschieht aber ohne unser zutun in der von EnOcean bereitgestellten Middleware. So das wir von dieser (zumindest sollten wir das) Werte von 0–70 in m/s erhalten. Die Rohdaten (0-255) sehen wir also gar nicht.
Die Skalierung findet nach folgender Formel statt:
float ScaleFromRAW(uint32_t rawValue, uint32_t rangeMin, uint32_t rangeMax, float scaleMin, float scaleMax)
{
float q = (scaleMax - scaleMin) / ((float) rangeMax - (float) rangeMin);
float scaledValue = q * ((float) rawValue - (float) rangeMin) + scaleMin;
return scaledValue;
}
Gerechnet wird mit diesen Werten:
// exist ,bitoffs,bitsize,rangeMin,rangeMax,scaleMin, scaleMax,type;
{ true, 16, 8, 0, 255, 0, 70.0, S_VELOCITY, 0 } //Wind speed
In meinen Augen ist diese Rechnung fehlerfrei. Demzufolge erhält homee Werte von 0-70 in m/s. Diese werden anschließend in km/h umgerechnet durch eine Multiplikation mit 3.6. Auch bei dieser Rechnung sehe ich keine Fehler.
Warum also vermeintlich nur ganzzahlige m/s Werte in homee ankommen kann ich mir nur so erklären:
Das Gerät schickt nur ganzzahlige Sensorwerte. Das heißt, dass lediglich Werte wie 0x03 (3), 0x07 (7), 0x0A(10), … über den Funk ankommen.
@anon11314990 Die Umrechnung in km/h findet aus exakt den Gründen statt die @SmartHomer genannt hat.
Nochmals Danke für Deine Ausführung, Thomas,
Da gibt’s nix zu Rütteln: Wenn die Skalierung in der Middleware das so macht, wie von Dir gepostet und ihr den ‘scaledValue’ “nur noch” mit 3,6 multipliziert, dann ist mathematisch alles korrekt.
Note 1 für den kleinen homee 
.