Ich erhalte seit einiger Zeit solche Meldungen bei mir im Log:
Argument "LR_SouthShutter" isn't numeric in numeric ne (!=) at ./FHEM/10_CUL_HM.pm line 1498.
Argument "LR_SouthShutter" isn't numeric in numeric ne (!=) at ./FHEM/10_CUL_HM.pm line 1498.
Argument "LR_SunBlind" isn't numeric in numeric ne (!=) at ./FHEM/10_CUL_HM.pm line 1498.
Argument "BR_Shutter" isn't numeric in numeric ne (!=) at ./FHEM/10_CUL_HM.pm line 1498.
Es scheint alles soweit zu funktionieren was meine Rollläden angeht. Die genannte Codestelle in 10_CUL_HM.pm sagt mir leider nichts :-(
Weiß jemand Rat?
Gruß
Julian
Zitat von: Loredo:Ich erhalte seit einiger Zeit solche Meldungen bei mir im Log:
Argument "LR_SouthShutter" isn't numeric in numeric ne (!=) at ./FHEM/10_CUL_HM.pm line 1498.
Die Meldung ist doch vergleichsweise einfach und klar:
Die Zeichenkette "LR_SouthShutter" wird mit einer Zahl verglichen, offensichtlich erwartet FHEM an der Stelle eine Zahl. Sollte das verkehrt sein, muß der Vergleich von "!=" in "ne" geändert werden.
Da die betreffende Zeile
@{$modules{CUL_HM}{helper}{reqStatus}} = grep { $_ != $shash->{NAME} }schwer nach Zeichenkette (string) aussieht, versuche mal dort das != gegen ne zu tauschen.
Falls Du Dich nicht traust, sollte der Autor das erledigen:
$Id: 10_CUL_HM.pm 3242 2013-06-02 17:53:42Z martinp876 $
ups, mir garnicht aufgefallen... werde ich erledigen
wenn Du eh grade an dieser Datei bist - hast Du das hier (http://forum.fhem.de/index.php?topic=13049.0) schon gesehen? Ich muss das nach jedem Update von Hand wieder ändern ;)
unklar.
Du willst das blank raushaben? Warum? mit blank kann man die Zahl besser auswerten und auch in plot verwenden.
Gegenargumente?
Ja, es geht mir nur um das Blank. Es ist in FHEM nämlich nicht einheitlich geregelt. Bei FHT80b wird z.B. kein Leerzeichen geliefert.
Gegenargument: Wer das Ganze irgendwie auswerten (im Sinne von splitten) will, kann genausogut das % Zeichen regexen ;)
Es sieht einfach unschön aus:
(http://up.picr.de/14796931dj.png)
schlimm genug, dass nicht einfach nur der Zahlenwert ohne jegliche Einheit zurückgeliefert wird *duck-und-weg*
Hi,
kuerzlich habe ich erst ein Blank eingebaut (muss ueberlegen wo) weil es mit dem Plotten nicht funktioniert hat. Falls du das Konzept des Plottens schon einmal angesehen hast es funktioniert anhand von Spalten, die durch Blank getrennt sind. Du 'grepst' also deine readings in ein File. Dan sagst du in der wievielten Spalte der Wert steht, ohne Einheit, und hast quasi deinen Plot. Das ganze wird fuer einfach User recht komplex, es mit regex zu erschlagen.
Solange das Plotten so funktioniert sollten alle Werte, die man plotten koennen wollte auch entsprechend darstellen, also mit Blank. Und daran koennte man den Standard festmachen und alle Werte so schreiben.
Ich kann mit beidem Leben, einheitlich sollte es sein... ich werde einmal forschen, wie sich FHEM entscheidet.
Gruss Martin
Den Actuator Wert gibt es ja mehrfach. Das Blank stört NUR an dieser einen Stelle in der Ausgabe. Ja, ich weiss wie das mit den Spalten beim Plotten funktioniert. Und es funktioniert sowohl mit FHT80b (wo es das Blank nicht gibt) als auch mit HM (mit Blank) - also das ist für mich kein eindeutiger Grund ;)
Ja, es sollte einheitlich sein...
(http://up.picr.de/14810874ap.png)
soviel zum Thema Einheitlichkeit... Nirgends Einheiten dabei, ausser an diesem Sch... actuator. Wer das Leerzeichen zum Parsen wirklich braucht, kann ja immer noch den Wert aus dem Climate verwenden. da stört (mich) das Leerzeichen überhaupt nicht ;)
Vielleicht sollte man die Einheiten vorbauen
Actuator[%] 63
Mal sehen, ob ich eine "Richtlinie" erhalten... Bin noch dran
Warum gibt es diese Einheit nur beim Stellantrieb und bei keinem anderen Meßwert des Thermostaten?
Pragmatischste Lösung: lass diese völlig überflüssige Einheit einfach komplett weg - genau wie bei Temperatur und Luftfeuchtigkeit auch. Zum Plotten (wie von Dir beschrieben) braucht man das Prozentzeichen ohnehin nicht, und wer eine Darstellung mit Prozentzeichen bauen will (so wie ich) kann das völlig problemlos einfach als String, wahlweise mit oder ohne Leerzeichen dazwischen, hinter den ausgelesen Wert ergänzen.
Prozentzeichen voranstellen wäre auf jeden Fall eine noch schlechtere Lösung als die jetzige.
Übrigens - nur so als Vergleich unter Entwicklerkollegen: als Softwareentwickler für betriebswirtschaftliche Software würde ich von meinen Kunden vermutlich erschlagen werden, wenn ich eine Währungseinheit mit in ein Betragsfeld schreiben würde.
ich glaube der vergleich hinkt...
deine kunden würden dich erschlagen wenn es keine andere möglichket gäbe als die währung fest als string dahinter zu kopieren und sie nicht mit der grösse verknüpft wäre. ich vermute deine software soll mit mehr als einer währung und das vielleicht sogar gemischt klar kommen..
gruss
andre
Hallo Martin,
ich hoffe du bist der richtige, ich habe seit dem allerneusten Update nun auch eine Fehlermeldung in 10_CUL_HM.
Immer wenn ich mein HM-OU-LED16 das ilum umschalten will, dann gibt mein perl folgendes aus:
Illegal hexadecimal digit ' ' ignored at ./FHEM/10_CUL_HM.pm line 1966.
Illegal hexadecimal digit ' ' ignored at ./FHEM/10_CUL_HM.pm line 1967.
Das liegt (so meine Recherche) daran:
$adList .= sprintf("%02X%02X",hex($addr),hex($data)) if ($addr ne "00");
und zwar, dass in $addr sowas steht wie ' 0F' (man beachte das space vor 0F), und dann
macht woll die hex funktion diesen Hinweis.....
Beholfen habe ich mich notdürftig mit:
if ( substr ( $addr, 0, 1 ) eq " " )
{
$addr= substr ( $addr, 1, length($addr)-1 );
}
Ist natürlich keine Lösung.....
Kannst du mal reinschauen ?
VG
mcfly
ok, wir laufen direkt in eine Grundsatzdiskussion. Sehr viele Aspekte, anschauungen und Handhabungen.
Ich denke dein Kunde wuerde dich erschlagen fuer beides
- Einheit im Betragsfeld
- Darstellung ohne Einheiten
Wir haben es bei Readings mir beidem zu tun, einem User interface und einem mmi zur Weiterverarbeitung. Der Ansatz mit dem Blank ist ein (schwacher) Versuch ein "doppeltes Datenfeld" zu praesentieren. Es ist sowohl lesbar alsauch einfach maschinengaengig aufzubereiten.
Ich denke bei oneWire ist ein sehr genereller (und akademischer) Ansatz eingearbeitet. Hier ist jeder Wert (Details muss ich mir ggf ansehen) ein Value,Unit,Faktor/Formula. Die Datenfelder sind getrennt, der User kann alle Werte umrechnen (meter nach inch...) und Einheiten darstellen, abfragen oder ausblenden.
Damit kann man sowohl das User Interface bedienen alsauch das Maschineninterface.
Am User-Interface halte ich die Darstellung ohne Einheiten nicht fuer unguenstig.
Gruss Martin
Oh... sehe gerade, dass es dieses Thema auch schon gibt.....
Übrigens schreibt der auch ins logbuch nicht den befehl
CUL_HM set ilum x y
sondern halt
CUL_HM set STATUSANZEIGE regBulk RegL_00: 04:07 08:00 rxt:1
Ist das gewollt ? Das ist natürlich der Befehl, der wohl letztendlich geschickt wird,
aber zum logbuch lesen ist es natürlich ein wenig verwirrend... wäre aber nicht schlimm natürlich, wenn es so bleibt....
VG
mcfly
Hallo mcfly,
ist das der falsche Thread? ilum ist eine andere Baustelle.
Dennoch:
- Das mit dem Logbuch habe ich nicht beruecksichtigt.
- Register-settings wuerde ich gerne alle den gleiche Weg laufen lassen ueber setReg oder regbulk Ilum gab es schon vor dem kompletten Register-setting, daher habe ich es umgesetzt
=> funktioniert es bei dir nicht? Bitte beispiel im
Link (http://forum.fhem.de/index.php?topic=13299.msg81974#msg81974)
Gruss
Martin
Zitat von: martinp876 schrieb am Mi, 12 Juni 2013 10:23Wir haben es bei Readings mir beidem zu tun, einem User interface und einem mmi zur Weiterverarbeitung.
ja. Und wir haben zwei Readings, die letztendlich den gleichen Meßwert repräsentieren: Einmal im Device und einmal im Channel Climate.
Im Device sind alle anderen Messwerte ohne Einheiten angegeben, dann könnte man m.E. auch beim Stellantrieb auf die Einheit verzichten (wegen der Einheitlichkeit...)
Im Climate Channel, der genau die Stellantriebe darstellt, kann das Prozentzeichen gerne stehenbleiben, damit es einen Dienst an der Lesbarkeit verrichten kann.