FHEM Forum

Originally posted by: <email address deleted>

On 29 Jun., 08:36, pahenning wrote:
> Betreffend die Überarbeitung aller FHEM-Module: Halte ich für dringend
> nötig - Grundlage für alle Größen muss natürlich die IUPAP-Nomenklatur
> sein.

Ich habe auch einige FHEM-Module bereitgestellt.

Bitte stelle für mich als Informatiker, aber Nicht-Physiker dar:
- Warum "muss" es "natürlich" die IUPAP-Nomenklatur sein? Welche
Argumente gibt es dafür diese für FHEM einzusetzen?
- Wo finden die Programmierer von FHEM-Modulen verständliche
Informationen zur IUPAP-Nomenklatur. Da dies ein Open-Source-Projekt
ist, sollte diese Information frei verfügbar sein. Also bitte Links.

Wenn es gute Argumente gibt, lasse ich mich gerne überzeugen.
Ansonsten bleibt Deine Äußerung unverständlich.

Danke.

MfG Willi

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Originally posted by: <email address deleted>

1. "Natürlich" deshalb, weil hier physikalische Größen gemessen werden
und FHEM den Anspruch vertritt,
    international verwendbar zu sein.
2. Auch dem Informatiker sollte klar sein, dass man sich _gerade_ bei
einem Open Source-Projekt an internationale
    Standards halten sollte - zumindest lernen das die Informatiker,
die bei mir studieren.
3. Ein Link erübrigt sich, das hier Benötigte kann man in wenigen
Zeilen zusammenfassen
    (und wer dies wünscht, kann den Begriff "IUPAP Nomenklatur" gerne
bei Google eingeben):

    Temperatur T [in Grad Celsius]
    Luftdruck p  [ in hPa, Hektopascal]
    Strom I [in A, Ampere]
    Spannung U [in V, Volt]
    Leistung P [in W, oder kW]
    Energie W [in J oder kWh je nachdem, was zweckmäßig ist]

    Ein paar weitere sind noch nötig, z.B. A für die Fläche, d für den
Tag  etc.

    Spezielle Zweckbestimmungen werden durch nachgestellte kleine
Buchstaben gekennzeichnet. So etwa

    täglicher Energieverbrauch = Wd
    Gleichstromleistung = Pdc
    Vorlauftemperatur = Tv

    Wer für sein Programm unbedingt "sprechende" Variablennamen
verwenden will, sollte demnach nicht "current" als
    Abkürzung für die gegenwärtige Leistung nehmen. Sondern, wenn es
denn sein muss, P_current.

Wir leben in einer freien Welt, insofern wird sicher niemand
gezwungen, so zu verfahren. Es wäre aber an der Zeit,
einen Style-Guide für FHEM-Module zu verfassen - und gerne trage ich
ein Kapitel dazu bei. Aber ich werde mir sicher
nicht den Spaß antun, hier individuelle Überzeugungsarbeit zu leisten.

Gruß

Peter A. Henning

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Originally posted by: <email address deleted>

On 6 Jul., 08:46, pahenning wrote:
> 2. Auch dem Informatiker sollte klar sein, dass man sich _gerade_ bei
> einem Open Source-Projekt an internationale
>     Standards halten sollte - zumindest lernen das die Informatiker,
> die bei mir studieren.

Ist dies Deine Art der Kommunikation?

Wenn Du möchtest, dass Dir jemand zuhört, solltest Du den Professor an
der Uni lassen und nicht jeden als Deinen Studenten behandeln.

MfG Willi

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Originally posted by: <email address deleted>

On 6 Jul., 08:46, pahenning wrote:
> 2. Auch dem Informatiker sollte klar sein, dass man sich _gerade_ bei
> einem Open Source-Projekt an internationale
>     Standards halten sollte - zumindest lernen das die Informatiker,
> die bei mir studieren.

Diese Äußerung war wieder enorm zielführend. Danke.

Auch dem Professor sollte klar sein, dass man sogenannte Standards
zuerst prüfen sollte, bevor man diese einsetzt.

Den Unsinn von Standards habe ich selbst hautnah beim Aufbau des
Internets in Deutschland erlebt. Das Dogma bis Anfang der 90-er Jahre
in Deutschland nur ISO-Standards einzusetzen zu wollen (X.400, X.29, X.
25, etc.) hat dazu geführt, dass Deutschland nur sehr zögerlich an das
Internet angebunden wurde.
Noch in den 80er-Jahren hat man in DE das TCP/IP und das Internet
verteufelt, weil es ja keine Standards einsetzen würde (nämlich keine
ISO-Standards).

Da ist mir der Pragmatismus von demokratischen Internet-Gremien wie
IETF lieber als die Standardisierungen von ISO.

Standards sind also nicht nur gut, weil Sie als Standards bezeichnet
werden. Ich hoffe Deine Studenten lernen das auch.

MfG Willi

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Originally posted by: <email address deleted>

Am 07.07.2011 08:42, schrieb Willi:
> On 6 Jul., 08:46, pahenning  wrote:
>> 2. Auch dem Informatiker sollte klar sein, dass man sich _gerade_ bei
>> einem Open Source-Projekt an internationale
>>      Standards halten sollte - zumindest lernen das die Informatiker,
>> die bei mir studieren.
>
> Diese Äußerung war wieder enorm zielführend. Danke.
> Auch dem Professor sollte klar sein, dass man sogenannte Standards
> zuerst prüfen sollte, bevor man diese einsetzt.

Nun, es ging ja um die Bezeichnung/Einheiten von physikalischen Grössen
im FHEM Projekt.

Wenn man sich für die Bezeichnung und Einheiten innerhalb vom FHEM
an einen Standard halten würde der sich z.B. an SI orientiert wäre das IMHO nicht schlecht.
Dieser Standard müsste aber an die Randbedingungen des FHEM Projektes angepasst werden,
und müsste IMHO vom BDFL von FHEM zumindest initiiert werden.
( Benevolent Dictator for Life (BDFL) (Deutsch: wohlwollender Diktator auf Lebenszeit) )


> Den Unsinn von Standards habe ich selbst hautnah beim Aufbau des
> Internets in Deutschland erlebt. Das Dogma bis Anfang der 90-er Jahre
> in Deutschland nur ISO-Standards einzusetzen zu wollen (X.400, X.29, X.
> 25, etc.) hat dazu geführt, dass Deutschland nur sehr zögerlich an das
> Internet angebunden wurde.
> Noch in den 80er-Jahren hat man in DE das TCP/IP und das Internet
> verteufelt, weil es ja keine Standards einsetzen würde (nämlich keine
> ISO-Standards).

Standards können auch gesetzlich bindend sein.
In gewissen Geschäftsbereichen werden in Offerten verbindlich SI-Einheiten
vorgeschrieben.

In der Firma wo ich arbeite machen wir Messungen für Kunden aus den verschiedensten Ländern der Erde
und geben die Resultate aus den Messungen auf Datenträgern ab.
Zum Glück besteht weltweit Einigkeit darin, dass die dafür verwendeten Masseinheiten im SI-System (International
System of Units) abzugeben sind. Diese Standardisierung erleichtert uns die Arbeit enorm.

Weltweit?

Nein, es gibt noch 3 (drei) rückständige Nationen welche sich bis jetzt noch nicht zu diesem Standard entschliessen konnten,
nämlich: Liberia, Myanmar und die USA.

NB1:
The European Union _had_ a directive banning non-SI markings after 31 December 2009 on any goods imported into the European Union.
This would apply to all markings on products, enclosed directions and papers, packaging and advertisements. (Note "had"...)

NB2:
Reactions in the United States:
In spite of the extension till 2009, the provisions of this directive, in particular the provisions prohibiting dual labelling were
a cause of serious concern in the United States. In 2005 there were informal consultations between the USA and the EU. In 2006, the
U.S. Department of Commerce made U.S. companies aware of potential problems and lobbied for a further extension of dual labelling,
which would be more consistent with United States legislation, in particular the Federal Fair Packaging and Labeling Act. !!! In
this context, the directive was characterized by one person as "an example of a power mad megalomaniac bureaucracy run amok. !!!

Siehe auch: http://en.wikipedia.org/wiki/Directive_80/181/EEC


> Da ist mir der Pragmatismus von demokratischen Internet-Gremien wie
> IETF lieber als die Standardisierungen von ISO.

Wir mussten aus verschiedenen zum Teil widersprüchlichen Standards wie
ANSI/AIAA
Verständigungsnormen DFVLR
DIN 9300
ISO 1151
ISO 8855
LN 9300 Flugmechanik
...
einen für unser Umfeld konsistenten Standard für die Einheiten und Bezeichnungen entwickeln.
Der hat sich nun recht gut bewährt, auch weil er Gott sei Dank von den Vorgesetzten unterstützt wird.

Wenn dann die Kunden aus z.B. den USA halt "Btu" oder "Slug per foot second" wollen
rechnen wir ihnen das aus unseren standardisierten Werten aus.
Aber unsere Rechnungen sind konsistent in unserem Standard.


Das heisst:
Innerhalb von Systemgrenzen, z.B. FHEM, ist es sehr hilfreich,
sich einen Standard zu erschaffen,
(der sich an einem "offiziellen" Standard orientieren kann)
und sich dann daran zu halten.


> Standards sind also nicht nur gut, weil Sie als Standards bezeichnet
> werden. Ich hoffe Deine Studenten lernen das auch.

Etwas vom schlimmsten in dieser Richtung war, dass man MS-Windows als
"Industrie-Standard" bezeichnet hat.


Grüessli
--
Kurt Mueller

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Originally posted by: <email address deleted>

@Willi: "Standards prüfen vor dem Einsatz" ist in dieser generellen
Form einfach absoluter Unsinn - und es geht hier noch nicht einmal
nicht um den  Einsatz von technischen Verfahren, sondern um
Notationen.

@Kurt Mueller. Es geht aber nicht nur um Einheiten (da ist SI das
Richtige, Zustimmung), sondern um das Schreiben von "wartbarem" Code
und wiederverwendbaren Routinen. Wenn ich die Leistung als Wert
"current" angebe, ist das so fehleranfällig, dass es relativ
irrelevant wird, ob die Energie nachher in kWh, Joule, MeV  oder BTU
angegeben wird.

Gruß

Peter A. Henning

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

                                             

Am 06.07.2011 08:46, schrieb pahenning:
> 3. Ein Link erübrigt sich, das hier Benötigte kann man in wenigen
> Zeilen zusammenfassen

Die Entwickler haben hierzu bereits entschieden:



Diese Diskussion koennte auch in fhem-devel@googlegroups.com fortgesetzt
werden.

Viele Gruesse
Boris

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Originally posted by: <email address deleted>

Am 07.07.2011 21:05, schrieb pahenning:
> @Kurt Mueller. Es geht aber nicht nur um Einheiten (da ist SI das
> Richtige, Zustimmung), sondern um das Schreiben von "wartbarem" Code
> und wiederverwendbaren Routinen. Wenn ich die Leistung als Wert
> "current" angebe, ist das so fehleranfällig, dass es relativ
> irrelevant wird, ob die Energie nachher in kWh, Joule, MeV  oder BTU
> angegeben wird.

Ja, es sollte beides standardisiert sein, der Name und die Einheit.


Gemäss dem Posting von Boris Neubert gibt es ja einen FHEM Standard für die
Bezeichnungen und die Einheiten von physikalischen Grössen:
http://www.fhemwiki.de/index.php/DevelopmentInterfaces

Im Falle von Leistung sind es:
currentPower: float, indicates the current power (or average over last time interval) in kW
maxPower: float, indicates the maximum power measured since startup in kW

D.h.
Die Befolgung der Interface Definition ist zu empfehlen, oder zu fordern je nach Fall.



Die Frage ist ob die Interface Definition noch vollständig ist.



Grüessli
--
Kurt Mueller

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Originally posted by: <email address deleted>

Na prima, diese Anleitungen habe ich bisher nicht gesehen (was nicht
dafür spricht, dass gut darauf hingewiesen wird...)

Allerdings stolpere ich über verschiedene Sachen, diskutieren wir das
mal an einem Beispiel:

      currentPower: float, indicates the current power (or average
over last time interval) in kW
      -- Was soll denn das "current" dabei ? "Power" würde vollkommen
reichen - und die Verwendung von "currentPower" für einen gemittelten
Wert ist irreführend und sorgt bei gleichzeitiger Messung eines
Stromes nur für Verwirrung.

      maxPower: float, indicates the maximum power measured since
startup in kW
     -- Wieso "since startup" ? Das kann sich doch z.B. auch auf ein
bestimmtes Zeitintervall beziehen, etwa beim EM 1000

      totalEnergy: float, indicates the total energy consumed since
startup in kWh
      totalEnergyDay: float, indicates the total energy consumed since
midnight in kWh
      totalEnergyWeek: float, indicates the total energy consumed
since the beginning of the week in kWh
      totalEnergyMonth: float, indicates the total energy consumed
since the beginning of the month in kWh
     -- Was soll denn das "total" dabei ? Was für eine "EnergyDay"
sollte man denn sonst messen ? Im Begriff "Energie" steckt doch schon
die zeitliche Aufintegration der Leistung drin !

     Abgesehen von der semantischen Überflüssigkeit von "current" und
"total" kollidiert dies auch mit den anderen Vorschlägen - so etwa
wird ja angeregt, die Temperatur als "temperature" zu bezeichnen. Und
nicht als "currentTemperature" ...

Womit sich die Frage stellt: wer vergibt die Accounts für dieses
Wiki ?

Gruß Peter A. Henning

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

                                             

Am 09.07.2011 10:42, schrieb pahenning:
> Womit sich die Frage stellt: wer vergibt die Accounts für dieses
> Wiki ?

bevor hier in der Developer-Abteilung von fhemwiki.de munter geändert
wird: die Interface-Definition stellt den letzten Diskussionsstand der
fhem-Entwickler dar und steht weiter zur Diskussion. Dieses Thema
schläft derzeit, weil die Entwickler ihre Prioritäten anders gesetzt
haben als auf die grundsätzliche Überarbeitung von fhem zu fhem 6.

Achso, und die erwähnte Diskussion ist in fhem-devel@googlegroups.com.

Grüße
Boris

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com