Können wir zu Weihnachten vielleicht die standardisierten Battery Readings (https://forum.fhem.de/index.php/topic,87575.0.html) bei HM bekommen? :)
Index: FHEM/10_CUL_HM.pm
===================================================================
--- FHEM/10_CUL_HM.pm (revision 18043)
+++ FHEM/10_CUL_HM.pm (working copy)
@@ -1204,6 +1204,10 @@
}
$mh{devN} = $mh{devH}->{NAME}; # source device name
+ if(!defined($mh{devN})){
+ Log3 $mh{dstN},2,"CUL_HM received unknown device - autocreate might be disabled";
+ return;
+ }
if (CUL_HM_getAttrInt($mh{devN},"ignore")){
$defs{$_}{".noDispatchVars"} = 1 foreach (grep !/^$mh{devN}$/,@entities);
return (CUL_HM_pushEvnts(),$mh{devN},@entities);
@@ -1493,7 +1497,7 @@
elsif($mh{md} =~ m/^(KS550|KS888|HM-WDS100-C6-O)/) { ########################
if($mh{mTp} eq "70") {
my ($t,$h,$r,$w,$wd,$s,$b) = map{hex($_)} unpack 'A4A2A4A4(A2)*',$mh{p};
- push @evtEt,[$mh{devH},1,"battery:". (($t & 0x8000)?"low" :"ok" )] if ($mh{md} eq "HM-WDS100-C6-O-2"); #has no battery
+ push @evtEt,[$mh{devH},1,"batteryState:". (($t & 0x8000)?"low" :"ok" )] if ($mh{md} eq "HM-WDS100-C6-O-2"); #has no battery
my $tsgn = ($t & 0x4000);
$t = ($t & 0x3fff)/10;
$t = sprintf("%0.1f", $t-1638.4) if($tsgn);
@@ -1525,7 +1529,7 @@
push @evtEt,[$mh{cHash},1,"storm:$txt"];
push @evtEt,[$mh{devH} ,1,"trig_$mh{chnHx}:$mh{dstN}"];
my $err = $chn & 0x80;
- push @evtEt,[$mh{devH},1,"battery:". ($err?"low" :"ok" )] if ($mh{md} eq "HM-WDS100-C6-O-2"); #has no battery
+ push @evtEt,[$mh{devH},1,"batteryState:". ($err?"low" :"ok" )] if ($mh{md} eq "HM-WDS100-C6-O-2"); #has no battery
}
else {
push @evtEt,[$mh{shash},1,"unknown:$mh{p}"];
@@ -1590,7 +1594,7 @@
$chnHash->{helper}{needUpdate} = 1 if($mode =~ m/central/ && $mh{mTp} eq '10');
}
push @evtEt,[$mh{shash},1,"desired-temp:$dTemp"];
- push @evtEt,[$mh{devH},1,"battery:".($err&0x80?"low":"ok")];
+ push @evtEt,[$mh{devH},1,"batteryState:".($err&0x80?"low":"ok")];
}
elsif( $mh{mTp} eq "10" && # Config change report
($mh{p} =~ m/^0402000000000501/)) { # paramchanged L5
@@ -1638,7 +1642,7 @@
if($modules{CUL_HM}{defptr}{"$mh{src}$chn"});
my $stErr = ($err >>1) & 0x7; # Status-Byte Evaluation
- push @evtEt,[$mh{devH},1,"battery:".(($stErr == 4)?"critical":($err&0x80?"low":"ok"))];
+ push @evtEt,[$mh{devH},1,"batteryState:".(($stErr == 4)?"low":($err&0x80?"low":"ok"))];
if (!$stErr){#remove both conditions
push @evtEt,[$mh{devH},1,"motorErr:ok"];
}
@@ -1646,7 +1650,7 @@
push @evtEt,[$mh{devH},1,"motorErr:blocked" ]if($stErr == 1);
push @evtEt,[$mh{devH},1,"motorErr:loose" ]if($stErr == 2);
push @evtEt,[$mh{devH},1,"motorErr:adjusting range too small"]if($stErr == 3);
-# push @evtEt,[$mh{shash},1,"battery:critical" ]if($stErr == 4);
+# push @evtEt,[$mh{shash},1,"batteryState:low" ]if($stErr == 4);
}
push @evtEt,[$mh{devH},1,"motor:opening"] if(($err&0x30) == 0x10);
push @evtEt,[$mh{devH},1,"motor:closing"] if(($err&0x30) == 0x20);
@@ -1694,7 +1698,7 @@
push @evtEt,[$mh{shash},1,"ValvePosition:$vp" ];
#device---
push @evtEt,[$mh{devH},1,"measured-temp:$actTemp"];
- push @evtEt,[$mh{devH},1,"batteryLevel:$bat"];
+ push @evtEt,[$mh{devH},1,"batteryVoltage:$bat"];
push @evtEt,[$mh{devH},1,"actuator:$vp"];
if ($err == 6){ $lBat = "low";}
elsif($err == 0){ $lBat = "ok";}# we cannot determin bat if any other state!
@@ -1757,7 +1761,7 @@
#push @evtEt,[$mh{shash},1,"unknown0:$uk0"];
#push @evtEt,[$mh{shash},1,"unknown1:".$2 if ($p =~ m/^0A(.10)(.*)/)];
push @evtEt,[$mh{devH},1,"motorErr:$errTbl{$err}" ] if($mh{mTp} eq "10");
- push @evtEt,[$mh{devH},1,"battery:$lBat"] if ($lBat);
+ push @evtEt,[$mh{devH},1,"batteryState:$lBat"] if ($lBat);
push @evtEt,[$mh{devH},1,"desired-temp:$setTemp"];
}
elsif($mh{mTp} eq "59" && defined $mI[0]) {#inform team about new value
@@ -1800,7 +1804,7 @@
$actTemp = sprintf("%2.1f",$actTemp);
push @evtEt,[$mh{cHash},1,"measured-temp:$actTemp"];
push @evtEt,[$mh{devH},1,"measured-temp:$actTemp"];
- push @evtEt,[$mh{devH},1,"batteryLevel:$bat"];
+ push @evtEt,[$mh{devH},1,"batteryVoltage:$bat"];
$cRep = (($cRep >>6) & 0x01 )?"on":"off";
$wRep = (($wRep >>5) & 0x01 )?"on":"off";
}
@@ -1848,7 +1852,7 @@
push @evtEt,[$mh{cHash},1,"commReporting:$cRep"];
push @evtEt,[$mh{cHash},1,"winOpenReporting:$wRep"];
push @evtEt,[$mh{cHash},1,"boostTime:$bTime"];
- push @evtEt,[$mh{devH},1,"battery:".($lbat?"low":"ok")];
+ push @evtEt,[$mh{devH},1,"batteryState:".($lbat?"low":"ok")];
push @evtEt,[$mh{devH},1,"desired-temp:$setTemp"];
}
elsif($mh{mTp} eq "70"){
@@ -1903,7 +1907,7 @@
push @evtEt,[$mh{shash},1,"level:$lvl"] if($mh{md} eq "HM-Sen-Wa-Od");
push @evtEt,[$mh{shash},1,"state:$lvl"];
- push @evtEt,[$mh{devH} ,1,"battery:".($err&0x80?"low":"ok")] if ($err ne "");
+ push @evtEt,[$mh{devH} ,1,"batteryState:".($err&0x80?"low":"ok")] if ($err ne "");
}
}
elsif($mh{md} eq "KFM-Sensor") { ############################################
@@ -1910,7 +1914,7 @@
if ($mh{mTp} eq "53"){
if($mh{p} =~ m/^(..)4(.)0200(..)(..)(..)/) {
my ($chn,$seq, $k_v1, $k_v2, $k_v3) = (hex($1),hex($2),$3,hex($4),hex($5));
- push @evtEt,[$mh{devH},1,"battery:".($chn & 0x80?"low":"ok")];
+ push @evtEt,[$mh{devH},1,"batteryState:".($chn & 0x80?"low":"ok")];
my $v = 1408 - ((($k_v3 & 0x07)<<8) + $k_v2);
push @evtEt,[$mh{shash},1,"rawValue:$v"];
my $nextSeq = ReadingsVal($mh{devN},"Sequence","");
@@ -1952,7 +1956,7 @@
$t = sprintf("%0.1f", $t/10);
my $statemsg = "state:T: $t";
push @evtEt,[$mh{shash},1,"temperature:$t"];#temp is always there
- push @evtEt,[$mh{devH},1,"battery:".($d1 & 0x8000?"low":"ok")];
+ push @evtEt,[$mh{devH},1,"batteryState:".($d1 & 0x8000?"low":"ok")];
if($modules{CUL_HM}{defptr}{$mh{src}.$chn}){
my $ch = $modules{CUL_HM}{defptr}{$mh{src}.$chn};
push @evtEt,[$ch,1,$statemsg];
@@ -1964,7 +1968,7 @@
}
elsif ($mh{mTp} eq "53"){
my ($chn,@dat) = unpack 'A2(A6)*',$mh{p};
- push @evtEt,[$mh{devH},1,"battery:".(hex($chn)&0x80?"low":"ok")];
+ push @evtEt,[$mh{devH},1,"batteryState:".(hex($chn)&0x80?"low":"ok")];
foreach (@dat){
my ($a,$d) = unpack 'A2A4',$_;
$d = hex($d);
@@ -2250,10 +2254,10 @@
elsif ($mh{md} eq "HM-SEC-SFA-SM"){
push @evtEt,[$mh{devH},1,"powerError:" .(($err&0x02) ? "on":"off")];
push @evtEt,[$mh{devH},1,"sabotageError:".(($err&0x04) ? "on":"off")];
- push @evtEt,[$mh{devH},1,"battery:".(($err&0x08)?"critical":($err&0x80?"low":"ok"))];
+ push @evtEt,[$mh{devH},1,"batteryState:".(($err&0x08)?"low":($err&0x80?"low":"ok"))];
}
elsif ($mh{md} =~ m/^(HM-LC-SW.-BA-PCB|HM-Dis-TD-T)/){
- push @evtEt,[$mh{devH},1,"battery:" . (($err&0x80) ? "low" : "ok" )];
+ push @evtEt,[$mh{devH},1,"batteryState:" . (($err&0x80) ? "low" : "ok" )];
}
}
}
@@ -2274,7 +2278,7 @@
$state .= ((($mh{mFlgH} & 0x24) == 0x20) ? "Release" : "");
}
- push @evtEt,[$mh{devH},1,"battery:$bat"];
+ push @evtEt,[$mh{devH},1,"batteryState:$bat"];
push @evtEt,[$mh{devH},1,"state:$btnName $state"];
if($mh{md} eq "HM-Dis-WM55"){
if ($mh{devH}->{cmdStack}){# there are pending commands. we only send new ones
@@ -2319,7 +2323,7 @@
$chn = sprintf("%02X",$chn & 0x3f);
$mh{shash} = $modules{CUL_HM}{defptr}{"$mh{src}$chn"}
if($modules{CUL_HM}{defptr}{"$mh{src}$chn"});
- push @evtEt,[$mh{devH},1,"battery:". ($err?"low" :"ok" )];
+ push @evtEt,[$mh{devH},1,"batteryState:". ($err?"low" :"ok" )];
}
elsif(($mh{mTp} eq "10" && $mI[0] eq "06") ||
($mh{mTp} eq "02" && $mI[0] eq "01")) {
@@ -2328,7 +2332,7 @@
$mh{shash} = $modules{CUL_HM}{defptr}{"$mh{src}$chn"}
if($modules{CUL_HM}{defptr}{"$mh{src}$chn"});
push @evtEt,[$mh{devH},1,"alive:yes"];
- push @evtEt,[$mh{devH},1,"battery:". (($err&0x80)?"low" :"ok" )];
+ push @evtEt,[$mh{devH},1,"batteryState:". (($err&0x80)?"low" :"ok" )];
}
if (defined($state) && $chn ne "00"){# if state was detected post events
@@ -2369,7 +2373,7 @@
push @evtEt,[$mh{cHash},1,"timedOn:$timedOn"];
push @evtEt,[$mh{devH} ,1,"powerOn:$mh{tmStr}",] if ($chn == 0) ;
push @evtEt,[$mh{devH} ,1,"sabotageError:".(($err&0x04)?"on" :"off")];
- push @evtEt,[$mh{devH} ,1,"battery:" .(($err&0x80)?"low":"ok" )];
+ push @evtEt,[$mh{devH} ,1,"batteryState:" .(($err&0x80)?"low":"ok" )];
}
}
elsif($mh{st} eq "senBright") { #############################################
@@ -2376,7 +2380,7 @@
if ($mh{mTp} =~ m/^5[34]/){
#Channel is fixed 1
my ($chn,$unkn,$dat) = unpack 'A2A2A8',$mh{p};# chn = 01
- push @evtEt,[$mh{devH},1,"battery:".(hex($chn)&0x80?"low":"ok")];
+ push @evtEt,[$mh{devH},1,"batteryState:".(hex($chn)&0x80?"low":"ok")];
$dat = sprintf("%0.2f",hex($dat))/100; #down to 0.01lux per docu
@@ -2399,7 +2403,7 @@
$mh{shash} = $modules{CUL_HM}{defptr}{$chId}
if($modules{CUL_HM}{defptr}{$chId});
- push @evtEt,[$mh{devH},1,"battery:".(($err&0x80)?"low" :"ok" )];
+ push @evtEt,[$mh{devH},1,"batteryState:".(($err&0x80)?"low" :"ok" )];
push @evtEt,[$mh{shash},1,"state:$val"];
}
@@ -2406,7 +2410,7 @@
elsif ($mh{mTp} eq "60" ||$mh{mTp} eq "61" ) { # IEC_POWER_EVENT_CYCLIC
my ($chn,$eUnit,$eCnt,$pUnit,$pIEC) = map{hex($_)} unpack 'A2A2A10A2A8',$mh{p};
- push @evtEt,[$mh{devH},1,"battery:".(($chn&0x80)?"low" :"ok" )];
+ push @evtEt,[$mh{devH},1,"batteryState:".(($chn&0x80)?"low" :"ok" )];
$chn = sprintf("%02X",$chn&0x3f);
my $chId = $mh{src}.$chn;
$mh{shash} = $modules{CUL_HM}{defptr}{$chId}
@@ -2562,7 +2566,7 @@
($state,$err) = ($1,hex($2)) if ($mh{p} =~ m/^....(..)(..)/);
# not sure what level are possible
push @evtEt,[$mh{cHash},1,"state:" .($state eq '00'?"ok":"level:".$state)];
- push @evtEt,[$mh{devH} ,1,"battery:".(($err&0x80)?"low" :"ok" )];
+ push @evtEt,[$mh{devH} ,1,"batteryState:".(($err&0x80)?"low" :"ok" )];
my $flag = ($err>>4) &0x7;
push @evtEt,[$mh{cHash},1,"flags:" .(($flag)?"none" :$flag )];
}
@@ -2636,7 +2640,7 @@
my $val = hex($mI[2])/2;
$val = ($val == 100 ? "on" : ($val == 0 ? "off" : "$val %"));
push @evtEt,[$mh{cHash},1,"state:$val"];
- push @evtEt,[$mh{devH} ,1,"battery:".(hex($mI[3]&0x80)?"low":"ok" )]if ($mh{md} eq "HM-OU-CFM-TW" && $mI[3]);
+ push @evtEt,[$mh{devH} ,1,"batteryState:".(hex($mI[3]&0x80)?"low":"ok" )]if ($mh{md} eq "HM-OU-CFM-TW" && $mI[3]);
}
}
@@ -2656,11 +2660,11 @@
else{
push @evtEt,[$mh{shash},1,"cover:". (($err&0x0E)?"open" :"closed")];
}
- push @evtEt,[$mh{devH},1,"battery:". (($err&0x80)?"low" :"ok" )];
+ push @evtEt,[$mh{devH},1,"batteryState:". (($err&0x80)?"low" :"ok" )];
}
elsif($mh{mTp} eq "41") {#01 is channel
my($chn,$cnt,$bright,$nextTr) = map{hex($_)} (@mI,0);
- push @evtEt,[$mh{devH},1,"battery:".($chn&0x80?"low":"ok")]; # observed with HM-SEN-MDIR-SM FW V1.6
+ push @evtEt,[$mh{devH},1,"batteryState:".($chn&0x80?"low":"ok")]; # observed with HM-SEN-MDIR-SM FW V1.6
if ($nextTr){
$nextTr = (15 << ($nextTr >> 4) - 4); # strange mapping of literals
RemoveInternalTimer($mh{cName}.":motionCheck");
@@ -2699,7 +2703,7 @@
# m:A0 A010 233FCE 1743BF 0601 01 00 31
my ($state,$err) = (hex($1),hex($2));
- push @evtEt,[$mh{devH} ,1,"battery:" .(($err&0x80)?"low" :"ok")];
+ push @evtEt,[$mh{devH} ,1,"batteryState:" .(($err&0x80)?"low" :"ok")];
push @evtEt,[$mh{cHash},1,"level:" .hex($state)];
$state = (($state < 2)?"off":"smoke-Alarm");
push @evtEt,[$mh{cHash},1,"state:$state"];
@@ -2763,7 +2767,7 @@
$mh{shash} = $modules{CUL_HM}{defptr}{"$mh{src}$chn"}
if($modules{CUL_HM}{defptr}{"$mh{src}$chn"});
push @evtEt,[$mh{devH},1,"alive:yes"];
- push @evtEt,[$mh{devH},1,"battery:". (($err&0x80)?"low" :"ok" )];
+ push @evtEt,[$mh{devH},1,"batteryState:". (($err&0x80)?"low" :"ok" )];
if ( $mh{md} =~ m/^(HM-SEC-SC.*|HM-SEC-RHS|Roto_ZEL-STG-RM-F.K)$/){
push @evtEt,[$mh{devH},1,"sabotageError:".(($err&0x0E)?"on" :"off")];}
elsif($mh{md} ne "HM-SEC-WDS"){push @evtEt,[$mh{devH},1,"cover:" .(($err&0x0E)?"open" :"closed")];}
@@ -2774,7 +2778,7 @@
$chn = sprintf("%02X",$chn & 0x3f);
$mh{shash} = $modules{CUL_HM}{defptr}{"$mh{src}$chn"}
if($modules{CUL_HM}{defptr}{"$mh{src}$chn"});
- push @evtEt,[$mh{devH},1,"battery:". ($err?"low" :"ok" )];
+ push @evtEt,[$mh{devH},1,"batteryState:". ($err?"low" :"ok" )];
push @ack,$mh{shash},$mh{mNo}."8002".$mh{dst}.$mh{src}."00"
if ( $ioId eq $mh{dst}
&& !$mh{devH}{IODev}->{helper}{VTS_ACK}
@@ -2803,6 +2807,7 @@
$lvl = hex($lvl)/2;
my $dat4 = ($stat >> 4) & 0x03;
if ($chn eq "01"){
+ push @evtEt,[$mh{shash},1,"state:".($lvlS ? "locked" : $lvl) ];
my %err = (0=>"ok",1=>"TurnError",2=>"TiltError");
my %dir = (0=>"no",1=>"up",2=>"down",3=>"undefined");
push @evtEt,[$mh{shash},1,"motorErr:" .$err{($stat >> 1) & 0x03}];
@@ -2812,10 +2817,11 @@
}
else{ #should be akku
my %statF = (0=>"trickleCharge",1=>"charge",2=>"discharge",3=>"unknown");
- push @evtEt,[$mh{shash},1,"charge:" .$statF{$dat4}];
+ push @evtEt,[$mh{shash},1,"batteryCharge:" .$statF{$dat4}];
+ push @evtEt,[$mh{shash},1,"batteryPercent:".($lvl)];
+ push @evtEt,[$mh{shash},1,"batteryState:".($lvl>20 ? "ok" : "low")];
}
# stateflag meaning unknown
- push @evtEt,[$mh{shash},1,"state:".($lvlS ? "locked" : $lvl) ];
}
}
elsif($mh{st} eq "keyMatic") { #############################################
@@ -2843,7 +2849,7 @@
$state = " (uncertain)";
}
push @evtEt,[$mh{shash},1,"unknown:40"] if($err&0x40);
- push @evtEt,[$mh{devH} ,1,"battery:" .(($err&0x80) ? "low":"ok")];
+ push @evtEt,[$mh{devH} ,1,"batteryState:" .(($err&0x80) ? "low":"ok")];
push @evtEt,[$mh{shash},1,"uncertain:" .(($err&0x30) ? "yes":"no")];
push @evtEt,[$mh{shash},1,"direction:" .$dir{($err>>4)&3}];
push @evtEt,[$mh{shash},1,"error:" . ($error)];
@@ -3584,7 +3590,7 @@
my $trgCnt = hex(substr($p,2,2));
my $err = hex(substr($p,0,2));
push @evtEt,[$sHash,1,"teamCall:from $dName:$trgCnt"];
- push @evtEt,[$dHash,1,"battery:" .(($err&0x80) ? "low":"ok")] if (!$dHash->{helper}{role}{vrt});
+ push @evtEt,[$dHash,1,"batteryState:" .(($err&0x80) ? "low":"ok")] if (!$dHash->{helper}{role}{vrt});
foreach (split ",",$attr{$sName}{peerIDs}){
my $tHash = CUL_HM_id2Hash($_);
push @evtEt,[$tHash,1,"teamCall:from $dName:$trgCnt"];
@@ -3676,7 +3682,7 @@
push @evtEt,[$_,1,"state:$sProsa"];
push @evtEt,[$_,1,"smoke_detect:$smokeSrc"];
}
- push @evtEt,[$dHash,1,"battery:" .((hex($chn)&0x80) ? "low":"ok")] if (!$dHash->{helper}{role}{vrt});
+ push @evtEt,[$dHash,1,"batteryState:" .((hex($chn)&0x80) ? "low":"ok")] if (!$dHash->{helper}{role}{vrt});
push @evtEt,[$sHash,1,"eventNo:".$No];
Log3 $sHash,5,"CUL_HM $sName sdTeam: no:$No state:$state aesNo:$aesKNo aesStr:$aesStr";
@@ -11106,7 +11112,7 @@
</li>
<li><B>HM-CC-TC,ROTO_ZEL-STG-RM-FWT</B><br>
T: $t H: $h<br>
- battery:[low|ok]<br>
+ batteryState:[low|ok]<br>
measured-temp $t<br>
humidity $h<br>
actuator $vp %<br>
@@ -11138,8 +11144,8 @@
desired-temp $setTemp<br>
ValvePosition $vp %<br>
mode [auto|manual|party|boost]<br>
- battery [low|ok]<br>
- batteryLevel $bat V<br>
+ batteryState [low|ok]<br>
+ batteryVoltage $bat V<br>
measured-temp $actTemp<br>
desired-temp $setTemp<br>
actuator $vp %<br>
@@ -11148,7 +11154,7 @@
</li>
<li><B>HM-CC-VD,ROTO_ZEL-STG-RM-FSA</B><br>
$vp %<br>
- battery:[critical|low|ok]<br>
+ batteryState:[low|ok]<br>
motorErr:[ok|blocked|loose|adjusting range too small|opening|closing|stop]<br>
ValvePosition:$vp %<br>
ValveErrorPosition:$vep %<br>
@@ -11159,18 +11165,18 @@
</li>
<li><B>HM-CC-SCD</B><br>
[normal|added|addedStrong]<br>
- battery [low|ok]<br>
+ batteryState [low|ok]<br>
</li>
<li><B>HM-SEC-SFA-SM</B><br>
powerError [on|off]<br>
sabotageError [on|off]<br>
- battery: [critical|low|ok]<br>
+ batteryState: [low|ok]<br>
</li>
<li><B>HM-LC-BL1-PB-FM</B><br>
motor: [opening|closing]<br>
</li>
<li><B>HM-LC-SW1-BA-PCB</B><br>
- battery: [low|ok]<br>
+ batteryState: [low|ok]<br>
</li>
<li><B>HM-OU-LED16</B><br>
color $value # hex - for device only<br>
@@ -11228,7 +11234,7 @@
motionCount $cnt _next:$nextTr"-"[0x0|0x1|0x2|0x3|15|30|60|120|240|0x9|0xa|0xb|0xc|0xd|0xe|0xf]<br>
cover [closed|open] # not for HM-Sec-MDIR<br>
sabotageError [on|off] # only HM-Sec-MDIR<br>
- battery [low|ok]<br>
+ batteryState [low|ok]<br>
devState_raw.$d1 $d2<br>
</li>
<li><B>remote/pushButton/outputUnit</B><br>
@@ -11248,13 +11254,13 @@
Btn$x offLongRelease $counter (to $dest)<br>
</li>
<li><B>remote/pushButton</B><br>
- battery [low|ok]<br>
+ batteryState [low|ok]<br>
trigger [Long|Short]_$no trigger event from channel<br>
</li>
<li><B>swi</B><br>
Btn$x Short<br>
Btn$x Short (to $dest)<br>
- battery: [low|ok]<br>
+ batteryState: [low|ok]<br>
</li>
<li><B>switch/dimmer/blindActuator</B><br>
$val<br>
@@ -11274,7 +11280,7 @@
[off|smoke-forward|smoke-alarm] # for team members<br>
[normal|added|addedStrong] #HM-CC-SCD<br>
SDteam [add|remove]_$dname<br>
- battery [low|ok]<br>
+ batteryState [low|ok]<br>
smoke_detect [none|<src>]<br>
teamCall:from $src<br>
</li>
@@ -11283,7 +11289,7 @@
[wet|damp|dry] #HM-SEC-WDS only<br>
cover [open|closed] #HM-SEC-WDS and HM-Sec-RHS<br>
alive yes<br>
- battery [low|ok]<br>
+ batteryState [low|ok]<br>
contact [open|tilted|closed]<br>
contact [wet|damp|dry] #HM-SEC-WDS only<br>
sabotageError [on|off] #HM-SEC-SC only<br>
@@ -11292,7 +11298,7 @@
[locked|$value]<br>
motorErr [ok|TurnError|TiltError]<br>
direction [no|up|down|undefined]<br>
- charge [trickleCharge|charge|dischange|unknown]<br>
+ batteryCharge [trickleCharge|charge|dischange|unknown]<br>
airing [inactiv|$air]<br>
course [tilt|close]<br>
airing [inactiv|$value]<br>
@@ -11300,7 +11306,7 @@
</li>
<li><B>keyMatic</B><br>
unknown:40<br>
- battery [low|ok]<br>
+ batteryState [low|ok]<br>
uncertain [yes|no]<br>
error [unknown|motor aborted|clutch failure|none']<br>
lock [unlocked|locked]<br>
@@ -12496,7 +12502,7 @@
</li>
<li><B>HM-CC-TC,ROTO_ZEL-STG-RM-FWT</B><br>
T: $t H: $h<br>
- battery:[low|ok]<br>
+ batteryState:[low|ok]<br>
measured-temp $t<br>
humidity $h<br>
actuator $vp %<br>
@@ -12528,8 +12534,8 @@
desired-temp $setTemp<br>
ValvePosition $vp %<br>
mode [auto|manual|party|boost]<br>
- battery [low|ok]<br>
- batteryLevel $bat V<br>
+ batteryState [low|ok]<br>
+ batteryVoltage $bat V<br>
measured-temp $actTemp<br>
desired-temp $setTemp<br>
actuator $vp %<br>
@@ -12538,7 +12544,7 @@
</li>
<li><B>HM-CC-VD,ROTO_ZEL-STG-RM-FSA</B><br>
$vp %<br>
- battery:[critical|low|ok]<br>
+ batteryState:[low|ok]<br>
motorErr:[ok|blocked|loose|adjusting range too small|opening|closing|stop]<br>
ValvePosition:$vp %<br>
ValveErrorPosition:$vep %<br>
@@ -12549,18 +12555,18 @@
</li>
<li><B>HM-CC-SCD</B><br>
[normal|added|addedStrong]<br>
- battery [low|ok]<br>
+ batteryState [low|ok]<br>
</li>
<li><B>HM-SEC-SFA-SM</B><br>
powerError [on|off]<br>
sabotageError [on|off]<br>
- battery: [critical|low|ok]<br>
+ batteryState: [low|ok]<br>
</li>
<li><B>HM-LC-BL1-PB-FM</B><br>
motor: [opening|closing]<br>
</li>
<li><B>HM-LC-SW1-BA-PCB</B><br>
- battery: [low|ok]<br>
+ batteryState: [low|ok]<br>
</li>
<li><B>HM-OU-LED16</B><br>
color $value # in Hex - nur für Gerät<br>
@@ -12618,7 +12624,7 @@
motionCount $cnt _next:$nextTr"-"[0x0|0x1|0x2|0x3|15|30|60|120|240|0x9|0xa|0xb|0xc|0xd|0xe|0xf]<br>
cover [closed|open] # nicht bei HM-Sec-MDIR<br>
sabotageError [on|off] # nur bei HM-Sec-MDIR<br>
- battery [low|ok]<br>
+ batteryState [low|ok]<br>
devState_raw.$d1 $d2<br>
</li>
<li><B>remote/pushButton/outputUnit</B><br>
@@ -12638,13 +12644,13 @@
Btn$x offLongRelease $counter (to $dest)<br>
</li>
<li><B>remote/pushButton</B><br>
- battery [low|ok]<br>
+ batteryState [low|ok]<br>
trigger [Long|Short]_$no trigger event from channel<br>
</li>
<li><B>swi</B><br>
Btn$x Short<br>
Btn$x Short (to $dest)<br>
- battery: [low|ok]<br>
+ batteryState: [low|ok]<br>
</li>
<li><B>switch/dimmer/blindActuator</B><br>
$val<br>
@@ -12664,7 +12670,7 @@
[off|smoke-forward|smoke-alarm] # für Gruppenmitglieder<br>
[normal|added|addedStrong] #HM-CC-SCD<br>
SDteam [add|remove]_$dname<br>
- battery [low|ok]<br>
+ batteryState [low|ok]<br>
smoke_detect [none|<src>]<br>
teamCall:from $src<br>
</li>
@@ -12673,7 +12679,7 @@
[wet|damp|dry] #nur HM-SEC-WDS<br>
cover [open|closed] #HM-SEC-WDS und HM-Sec-RHS<br>
alive yes<br>
- battery [low|ok]<br>
+ batteryState [low|ok]<br>
contact [open|tilted|closed]<br>
contact [wet|damp|dry] #nur HM-SEC-WDS<br>
sabotageError [on|off] #nur HM-SEC-SC<br>
@@ -12690,7 +12696,7 @@
</li>
<li><B>keyMatic</B><br>
unknown:40<br>
- battery [low|ok]<br>
+ batteryState [low|ok]<br>
uncertain [yes|no]<br>
error [unknown|motor aborted|clutch failure|none']<br>
lock [unlocked|locked]<br>
Klar.
Hilfreichen als das angehängte diff welches ich sowieso in dieser Form und Länge nicht abgleichen wäre mir die Kurzfassung gewesen
Replace batterie batterieState
Replace...
Das ist einfach kurz und hilfreich. Jetzt müsste ich jede Zeile durchsuchen. Das macht normal mein Editor
Danke dennoch
Weil Weihnachten ist ;)
Geht es so zu machen wie bei dem FlowerSense Modul von CoolTux, also beides (eine Zeit lang) parallel aber das "alte Format" als deprecated (commandref)...
...oder zumindest deutlich irgendwo (aber wo!?) ankündigen!?
Weil sonst (vermutlich) (wieder) eine Flut von "meine Batterieüberwachung geht nach dem Update nicht mehr" zu erwarten ist... ;)
Gruß und frosch Fescht, Joachim
Ich schalten nur einmal um. Parallel macht keinen Sinn, verschiebt nur den Frust.
Den Updat habe ich fertig, kann aber natürlich noch warten und einmal posten (was hier eigentlich schon geschehen ist)
Ich habe hiermit mehrere formale Problem
- ich sehe keine neue Definition. Diese kann ich aus dem referenzierten Threat herausfiltern - und hoffen, dass nicht noch irgendwer eine Modifikation versteckt hat. Eine Spec wäre sinnvoll und hilfreich
- Mit der vorgeschlatenen Implementierung verschwindet der Level "critical" welcher von HM geliefert wird. Mir ist nicht klar, wie gut es funktioniert hat, aber nun fällt es der Vereinheitlichung zum Opfer
- Die Änderung kann - wie Joachim angemerkt hat - nicht angekündigt werden. Ein Umschalten ist immer Hart. Doppelte Readings in der Übergangsphase sind m.E. nicht sinnvoll
Also nicht zu weihnachten aber zu Beginn 2019 auf die Änderung vorbereiten. Spec zu den Readings bitte bei den "Kern-Entwicklern" einfordern.
ZitatMit der vorgeschlatenen Implementierung verschwindet der Level "critical" welcher von HM geliefert wird. Mir ist nicht klar, wie gut es funktioniert hat, aber nun fällt es der Vereinheitlichung zum Opfer
das gefällt mir ganz und gar nicht. >:(
Prinzipiell bin ich auch für eine Vereinheitlichung. Die nötigen Änderungen sind in diesem Fall aber nicht unerheblich.
Vor allem nutzt mir ein Vorpreschen bei Homematic nichts, wenn die anderen Modulersteller nicht zeitnah mitziehen. Dann muss ich meine Definitionen nämlich doch wieder in mehreren Schüben ändern.
Zitat von: martinp876 am 24 Dezember 2018, 13:44:25
Ich schalten nur einmal um. Parallel macht keinen Sinn, verschiebt nur den Frust.
1. Was genau spricht nochmal dagegen, eine Zeitlang parallel Readings zu befüllen? Einfach die (-)-Zeilen drin lassen und nur die (+) ergänzen?
2. Wieso "critical" durch "low" ersetzt werden
muss, erschließt sich mir auch noch nicht, da muss ich den zitierten Fred nochmal besser durchlesen.
Vor allem kann ich nicht einschätzen, welche Geräte eigentlich überhaupt "critical" liefern und warum. Bei mir gesehen habe ich es noch nie.
edit: sehe ich das richtig, dass das aktuell nur HM-SEC-SFA-SM (Sirenenansteuerung) und HM-CC-VD bzw. ROTO_ZEL-STG-RM-FSA (alter Heizkörperstellantrieb) betrifft?
Generell würde ich mir also wünschen:
1. parallele Readings
2. Wenn alle Module nachgezogen sind, Mitteilung an User mit Hinweis auf Änderung.
3. frühestens ein halbes Jahr später alte Readings abschalten.
Man meint nicht, wie selten manche Leute an ihre Installation gehen...
Jm2c.
Hi,
ich habe das zwar nie geprüft, aber ich bin immer davon ausgegangen, dass die Readings bei HM den Namen in den Gerätebeschreibungs-XMLs entsprechen. Außerdem bin ich davon ausgegangen, dass ein Modul wie CUL_HM möglichst das abbilden sollte, was die Geräte (bzw. deren Hersteller) vorgeben, auch wenn es anders ein bisschen "schöner" wäre. Alles andere müsste eine darüber liegende Schicht machen.
Oder kurz: Ich bin gegen eine solche "Vereinheitlichung" wenn sie von den Gerätebeschreibungs-XMLs abweicht.
Gruß,
Thorsten
Ja, schade, ist an mir völlig vorübergegangen.
Außer einer gewissen Datenredundanz als Nachteil sehe ich nach neuerlichem Studium des verlinkten Threads eigentlich überhaupt keinen Grund dagegen, die drei zusätzlichen Readings als FHEM-konforme Vereinheitlichung einzuführen, ohne die alten Readings überhaupt abzuschalten. Denn sowohl batteryState als auch batteryPercent haben in HM bisher keine Rolle gespielt, und batteryLevel kann so bleiben wie es ist, oder?
Abgesehen davon finde ich es schade, dass man sich aus Konsenzgründen bei batteryState auf "ok" und "low" beschränken will. Dafür gibt es technisch keinen Grund, denn eine solche Unterscheidung ist zumindest bei Batterien sehr wohl möglich. Und auch ein newbie interpretiert "low" als "muss mal gewechselt werden" und "critical" als "muss sofort gewechselt werden, weil Funktion gefährdet". Und wer in seinen Auswertungen partout weiterhin nur auf eq "low" triggern wollte, müsste es stattdessen auf ne "ok" tun - und gut.
Hingegen halte ich von einer Umrechnung von batteryLevel auf batteryState gar nix, weil es voraussetzt, dass der Typ der Batterie bekannt ist, denn Akkus haben ganz andere Spannungs-Restkapazitätskurven als Batterien. Aber das ist ja eh kein Thema für HM.
letzendlich liefert Homematic ja keine Texte sondern numerische Werte, die das jeweilige Modul "interpretiert". Wenn nun der neue "Standard" für ein Reading nur 2 Werte vorsieht, das Homematic Gerät jedoch >2 Zustände liefert, ist der neue "Standard" vielleicht suboptimal und man sollte ihn hinterfragen.
ZitatAbgesehen davon finde ich es schade, dass man sich aus Konsenzgründen bei batteryState auf "ok" und "low" beschränken will. Dafür gibt es technisch keinen Grund, denn eine solche Unterscheidung ist zumindest bei Batterien sehr wohl möglich. Und auch ein newbie interpretiert "low" als "muss mal gewechselt werden" und "critical" als "muss sofort gewechselt werden, weil Funktion gefährdet". Und wer in seinen Auswertungen partout weiterhin nur auf eq "low" triggern wollte, müsste es stattdessen auf ne "ok" tun - und gut.
zudem wirkt dieser umstand auf mich auch ziehmlich "absurd".
soweit ich es richtig verfolgt habe, versucht man im "batterie-modul"-thread (initiator der batterie-vereinheitlichung) aufwendig heraus zu finden, wie kritisch eine low message wirklich ist. eigentlich eine sinnvolle idee, da es ja wirklich eine enorme bandbreite gibt.
aber als folge der vereinheitlichung sollen nun devices, die diese gesuchte info bereits explizit liefern, "kastriert" werden.
bei meinen hm-cc-vd funktioniert low/critical ziehmlich gut. bei low besorg ich ggf demnächst neue batterien und bei critical wechsel ich zeitnah, damit ich nicht im kalten sitzen muss. sollte ich eine reise geplant haben wechsel ich natürlich ausnahmsweise bei low.
ein schritt in richtung: "fhem goes mainstream"
trotzdem wünsche ich allen entspannte tage. :)
gruss frank
"critical" hat - außer in der Aufzählung - ja keine Rolle im der Diskussion gespielt ... stattdessen wurde noch über "special" geredet ...
Wenn wir das alte "battery" in HM nicht abschalten (wofür es keine Veranlassung gibt wie ich schon sagte) können frank und diverse andere User weiterhin - ohne Patch- pünktlich Batterien wechseln ...
Auch von mir: Schöne Weihnachtstsge!
Meine Güte was für ein gewese. Was ist denn so schlimm daran den Standard für das Modul zu erweitern. Man bietet den Standard an und dokumentiert die Erweiterung (critical). Ist ja hier nichts in Stein gemeißelt. Die User müssen es halt nur wissen daß dies nur für das Modul gilt.
Also Ball flach und schick ist.
Grüße
Habe die Diskussion damals angestoßen und gerade diesen Thread gefunden. Ziel ist, dass der Wildwuchs eingefangen wird und es gewisse Standards gibt, nichts mehr und nichts weniger. In erster Linie gleiche Namen für die Readings :)
Ich weiß, es ist immer leicht hinterher zu meckern, aber ich finde den Namen "batteryLevel" nicht so glücklich, wenn damit immer die Spannung gemeint ist. Das geht aus dem Namen für mich nicht hervor, da "Level" unkonkret ist. Hätte da z.B. "batteryVoltage" besser gefunden.
Naja meckern tust ja nicht. Aber Du kommst zu spät damit. Hättest vor einem dreiviertel Jahr an der Diskussion teilnehmen müssen ;)
Also erst einmal implementieren wir Homematic nach FHEM und nicht umgekehrt. Ich bin ein Freund von Vereinheitlichungen...
nun die "abers" - welche mich zaudern lassen
1) zur Festlegung der Standardisierungen sehe ich kein Dokument (bspw wiki,...). Ein Threat kann eigentlich per definition keine Grundlage zur Änderung der Readings sein. Der kann sich jederzeit verändern
2) Vorstöße etwas zu standardisieren kommen immer wieder von einzelen und werden in einem belibigen Rahmen diskutiert (nicht geschlossen, aber man muss es erst einmal finden. Da gab es schon einige - und nicht alle sind sinnvoll.
3) Vereinheitlichungen müssen hinreichend felxibel und zukunftssicher sein sowie kompatibel und semantisch passend zum System
4) Berücksichtig werden muss nicht nur die syntaktische Korrektheit und der semantische Anspruch der aktuellen Diskussionsgruppe. Auch die Verbreitung der aktuellen Implementierungen. "battery" ist wohl schon seit Anbeginn von FHEM vorhanden. Dies zu ändern zu "batteryState" ist nicht lustig - und schöner reicht nicht als Argument.
=> Es Bedarf eines Kernteams welches die FHEM Philosophie, Notwendigkeit und zukunftsträchtigkeit eines Standardisierungsvorschlags betrachtet. Das Ergebnis MUSS in einem Dokument (wiki?) niedergeschrieben werden - NACH Review und Genehmigung der "Kerngruppe".
Das schränkt natürlich ein - aber es gibt nun einmal keine andere Möglichkeit Ruhe ud Systematik in die Readings zu bekommen.
Ich selbst habe weder die Zeit noch den Überblick solche (nicht einfachen) Fragen zu beantworten. Ich werden also auf das Dokument warten (und hoffe informiert zu werden , wenn dieser Teil definiert ist).
=> Planänderung: keine Änderung vor Freigabe des Dokuments zum Reading
Und weiter: natürlich ist es m.E. möglich, die aktuellen Anforderungen unter einen Hut zu bekommen. So könnte bspw zum primary-state des Readings batteryState (oder battery) einen secondary-state addieren. Neben 'low|ok' kann es einen parsable state 'low_critical' geben.
p.s.: Ich werde diesen Beitrag auch zur Diskussion der BAttery kopieren - wo es hin gehört.
Ich denke es sind erst einmal die key-Personen wie Rudi/Boris/... gefragt, hier präzise Regeln festzulegen
Zu Deinem 1.
https://wiki.fhem.de/wiki/DevelopmentGuidelinesReadings
Zitat von: martinp876 am 25 Dezember 2018, 09:17:07
=> Es Bedarf eines Kernteams welches die FHEM Philosophie, Notwendigkeit und zukunftsträchtigkeit eines Standardisierungsvorschlags betrachtet. Das Ergebnis MUSS in einem Dokument (wiki?) niedergeschrieben werden - NACH Review und Genehmigung der "Kerngruppe".
Hier stimme ich Dir voll und ganz zu. Ich denke auch das es ein Kernteam (FHEM e.V. ??) sein sollte welches so grundlegende Dinge beschließt.
Grüße
ZitatBatterie-Readings
Basierend auf dieser Diskussion haben sich die Entwickler für Readings, welche in Zusammenhang mit Batterien stehen auf folgendes geeinigt: Es gibt nur diese drei Readings für den Batteriestatus:
batteryState
batteryPercent
batteryVoltage
Wertebereich:
batteryState: ok|low
batteryPercent: \d{1,2}|100
batteryVoltage: \d+.\d+
Wichtig: das jeweilige Modul setzt nur die Readings, die es aus den aktuellen Daten vom Gerät bestimmen kann. Konkret: niemand kann sich darauf verlassen, welche der drei battery Readings vorhanden sind (es gibt nicht überall ein batteryState). Wenn das Gerät früher ein Percent gemeldet hat, aber in der letzten Nachricht nur state, dann wird das Percent Reading nicht angefasst.
nach dieser regel sehe ich keine möglichkeit einen batteriestatus=critical als reading zu presentieren.
1. weitere battery readings werden ausgeschlossen.
2. die wertebereiche der 3 nutzbaren readings verhindern die übergabe des wertes.
frage:
warum wurde eigentlich der wertebereich von batteryState auf low/ok begrenzt?
es wird wert darauf gelegt, dass "nur" gesendete werte in den readings erscheinen. aber warum wird kein wert darauf gelegt,
alle gesendeten werte in den readings auf nehmen zu können?
Zitat von: frank am 25 Dezember 2018, 12:06:05
warum wurde eigentlich der wertebereich von batteryState auf low/ok begrenzt?
<Vermutung>
Weil immer wieder die gleichen Leute nach dem Rauchen irgendwelcher bewußtseinserweiternder Substanzen mit solchen sinnfreien Ideen um die Ecke kommen, überall alles zum Kochen bringen und dann die Ideen nicht bis zum Ende fertigdenken. Vermutlich weil die Wirkung der Substanzen bis dahin schon nachgelassen hat.
</Vermutung>
Und auch in einem "Kernteam" würde es vermutlich nicht nur Nichtraucher geben.
Die Argumentation von martin kann ich zu 100% unterstützen.
ok, vielen dank für den Link. Ich werde es also umsetzen - wie gesagt in der ersten januarwoche. So haben alle eine Vorwarnzeit (wenn sie diesen Threat finden :( )
Ausser Batterie ist offensichtlich kein Reading definiert. Eigentlich schade.
Für alle, die einen Quicky für den Übergang brauchen:
mit UserReadings kann man sich behelfen. Allerdings "critical" ist ein Problem. Hier würde ich den kritischeren Fall voraussetzen und alle "neuen 'low'" auf "alte 'critical'" mappen.
Automatisch kann man das mit den Kommando
{foreach( devspec2array("TYPE=CUL_HM:FILTER=battery=..*:FILTER=userReadings!=.*batteryLevel.*")){$attr{$_}{userReadings}=(defined $attr{$_}{userReadings}?$attr{$_}{userReadings}.", ":"")."batteryLevel {ReadingsVal(\$NAME,\"batteryVoltage\",0)}, battery {ReadingsVal(\$NAME,\"batteryState\",0)eq\"ok\"?\"ok\":\"critical\"}"}}
erreichen - für User die hier eine solche Hilfe brauchen und suchen.
Für grundsätzliche Diskussionen zu den Batterie-readings bitte an die "Kerngruppe" wenden und dies im Wiki dokumentieren. Dann werde ich nachziehen - logisch.
Hi,
wenn es bei dieser Standardisierung nur darum geht, neue Readings einzuführen und die alten so bleiben, wie sie sind, dann bin ich auch dafür.
Allerdings wundere ich mich ein bisschen, dass der neue Standard anscheinend etwas an CUL_HM vorbeigeht. CUL_HM ist in FHEM das am meisten benutzte Modul (wenn man mal von Hilfsmodulen absieht). Daher hätte ich erwartet, dass jeder neue Standard ziemlich gut auf CUL_HM passt. (Außer es gibt gute Argumente dagegen.)
Kann man nach der Änderung das "critical" irgendwie zurück bekommen?
Gruß,
Thorsten
Zitat von: Thorsten Pferdekaemper am 25 Dezember 2018, 14:59:49
wenn es bei dieser Standardisierung nur darum geht, neue Readings einzuführen und die alten so bleiben, wie sie sind, dann bin ich auch dafür.
Martins erste Idee war ja, von heute auf morgen die alten abzuschalten und die neuen einzuführen. Das allerdings erst, sobald dies als Standard festgeschrieben ist.
Ob das zum jetzigen Zeitpunkt so ist, da halte ich mich raus.
ZitatAllerdings wundere ich mich ein bisschen, dass der neue Standard anscheinend etwas an CUL_HM vorbeigeht. CUL_HM ist in FHEM das am meisten benutzte Modul (wenn man mal von Hilfsmodulen absieht). Daher hätte ich erwartet, dass jeder neue Standard ziemlich gut auf CUL_HM passt. (Außer es gibt gute Argumente dagegen.)
Wenn ich den Verlauf der Diskussion so lese, waren sowohl das "critical" als auch "empty" etc. bei EnOcean sehr schnell unter den Tisch gefallen, als es um einen "kleinsten gemeinsamen Nenner" ging. Der bezog sich aber aus meiner Interpretation mehr auf die Anzahl und Benennung der Readings und nicht den Wertebereich. Dass man dann künftig hilfreiche und vorhandene Informationen ignoriert, war ja nie Gegenstand der Diskussion.
ZitatKann man nach der Änderung das "critical" irgendwie zurück bekommen?
Ich würde wie einige meiner Vorredner dringend dafür plädieren, den "Standard" nachzubessern. Es ist richtig, keine Readings zu "erfinden" (bzw. zu interpetieren aus anderen Infos), die das Gerät nicht liefert, aber wenn die Geräte - egal welchen Moduls - definitiv mehr Informationen liefern, macht es keinen Sinn, sie aus "Standardisierungsgründen" zu verwerfen. Selbst die von Amenophis86 geplante zentrale Batterieüberwachung dürfte davon profitieren. Und wie ich schon sagte: Wer partout für seine Zwecke nur zwei Zustände braucht, nämlich "ok" und "nicht ok", bekommt das problemlos auch mit größeren Wertebereichen hin, weil low, critical, empty und dead eben alles andere als "ok" sind.
Würde ich "critical" nutzen, käme bei einer modulbasierten Ignoranz CUL_HM künftig ins exclude und ich würde es nur noch händisch updaten. Das kann aber auch nicht Sinn der Übung sein.
Zitat von: martinp876 am 25 Dezember 2018, 09:17:07
... p.s.: Ich werde diesen Beitrag auch zur Diskussion der BAttery kopieren - wo es hin gehört.
Ja, mach mal. Ist bisher nicht passiert.
offensichtlich sind die entwickler von fhem überfordert mit kritischen batteriezuständen um zu gehen. scheinbar ist hier eine unüberwindbare grenze erreicht. wirklich schade.
seltsamer weise werden nun infos über systemkritische zustände kurzer hand einfach verworfen, als würden sie gar nicht existieren. und ich meine nicht nur batteryState=critical. es wird ja alles verworfen, was nicht low/ok ist. damit werden sogar alle zukünftig erfassbaren zustände bereits jetzt ausgeschlossen. zb eine früherkennung, um explodierende batterien zu verhindern.
diese tatsache finde ich immer unglaublicher, je länger ich darüber nachdenke. so krass sich betateilchens vermutung auch anhört, aber dem kern seiner aussage muss ich zustimmen: die derzeitig gültige regel kann nicht zu ende gedacht sein.
wäre diese regel auch entstanden, wenn zwave criticalBat senden würde? ;)
@martin
wenn du dich diesem irsinn schon anschliesst, würde ich dich bitten bei critical kein fake-low zu erzeugen. lieber gar nichts aktualisieren, dann könnte ich vielleicht über ausbleibende low/ok events auf critical rückschliessen.
oder schenke mir ein reading deviceError=criticalBat.
Ich hab das nicht bis in jeden Post verfolgt,
Aber IMHO ging es bei der Vereinheitlichung hauptsächlich um die Namen der Readings und weniger um den Inhalt.
Wenn es für den Batterie Zustand 15 verschieden benannte Readings gibt ist ja auch keinem geholfen.
Geht ja schon los mit "Battery", "battery", "Batterie" oder "Batterie"......
Über gültige Wertebereiche kann man ja dann abstimmen.
Einem ok/low auch ein critical zu spendieren sollte ja das kleinste Problem sein.
Ich denke wir wollen hier alle FHEM vorwärts bringen, das geht aber nur wenn auch alle an einem Strang ziehen und sich nicht hier zerfleischen. [emoji6]
Gesendet von meinem Doogee S60 mit Tapatalk
Ich finde diese ganze Diskussion sowas von ...
Was bitte schön ist daran so schwer einfach im Developer Forum ein critical zur Diskussion zu stellen. Ich behaupte Mal das niemand was dagegen hätte. Aber anscheinend ist es für ein paar Leute einfacher sich darüber tagelang das ... zu zerreißen wie Kurzsichtig aus deren Sicht gedacht wurde. Ja es würde hier eine gewisse Kurzsichtigkeit entdeckt, dann stellt es einfach zur Diskussion. Fehler sind dazu da um aus ihnen zu lernen. Und die jenigen die sich jetzt hier aufspielen hatten damals die Möglichkeit das auf zu machen welches sie sich aktuell zerreißen. Keine Meinung zu haben ist schlimmer wie eine Meinung zu haben und noch schlimmer ist es sich später darüber auf zu regen. Ist ja wie in der Politik hier, die Leute gehen bestimmt auch nicht wählen und Beschwerden sich im Nachhinein darüber wie Schei...e die Regierung ist.
Zitat von: CoolTux am 26 Dezember 2018, 18:35:23
Ich finde diese ganze Diskussion sowas von ...
Was bitte schön ist daran so schwer einfach im Developer Forum ein critical zur Diskussion zu stellen.
Ich sag's zum dritten Mal: Ich habe dort keine Schreibrechte, weil ich kein Developer bin ;)
Bist Du bitte so gut und fügst nach martins Statement von heute 17:xx nochmal etwas deutlicher an was unser (bisher einziges) Problem hier ist, etwa:
"Einige Homematic-Geräte liefern zusätzlich zu "low" einen weiteren Batteriestatus "critical". Dies drückt aus, dass die Batterien unmittelbar gewechselt werden müssen, weil die Funktionsfähigkeit des Gerätes sonst nicht mehr gegeben ist. Es ist nicht hinzunehmen, dass diese wichtige Warnung der angedachten Reduzierung des Wertebereichs auf "ok|low" zum Opfer fällt. Hier sollte nachgebessert werden."
und eventuell
BTW: Wenn in einer Auswertung unbedingt nur zwei Zustände anzunehmen sind, könnte man statt "low" auch auf 'ne "ok"' triggern."
Ich täte es selbst, aber wie gesagt, ich darf es nicht.
Davon abgesehen war ich überrascht zu sehen, dass meine Batterieüberwachung bei den FHT-Fenstersensoren bereits batteryState erwartet ...
Zitat von: Pfriemler am 26 Dezember 2018, 19:04:30
Ich sag's zum dritten Mal: Ich habe dort keine Schreibrechte, weil ich kein Developer bin ;)
Bist Du bitte so gut und fügst nach martins Statement von heute 17:xx nochmal etwas deutlicher an was unser (bisher einziges) Problem hier ist, etwa:
"Einige Homematic-Geräte liefern zusätzlich zu "low" einen weiteren Batteriestatus "critical". Dies drückt aus, dass die Batterien unmittelbar gewechselt werden müssen, weil die Funktionsfähigkeit des Gerätes sonst nicht mehr gegeben ist. Es ist nicht hinzunehmen, dass diese wichtige Warnung der angedachten Reduzierung des Wertebereichs auf "ok|low" zum Opfer fällt. Hier sollte nachgebessert werden."
und eventuell
BTW: Wenn in einer Auswertung unbedingt nur zwei Zustände anzunehmen sind, könnte man statt "low" auch auf 'ne "ok"' triggern."
Ich täte es selbst, aber wie gesagt, ich darf es nicht.
Davon abgesehen war ich überrascht zu sehen, dass meine Batterieüberwachung bei den FHT-Fenstersensoren bereits batteryState erwartet ...
Aber warum soll ich Martin entmündigen. Ist er nicht alt genug für sich und sein Modul entsprechend zu argumentieren.
Die wichtigen Punkte welche ein ordentliches Gewicht in die Waagschale werfen wurden doch genannt. Alter des Moduls und User. Das berechtigt auf alle Fälle eine Diskussion und ich stimme persönlich für die Erweiterung. Und ja man kann später auch über eine Zustandsmeldung nach denken oder dafür ein eigenes Reading nehmen.
Aber es muss darüber erstmal geredet werden. Als Developer hat man nicht nur das Recht Module zu entwickeln und sie offiziell zu machen sondern auch die Pflicht sofern man Teil der Entwicklung sein will an Entwicklungsdiskussionen teil zu nehmen. Tut man dies nicht und meckert Monate später über die Entscheidung wirft das in meinen Augen kein gutes Licht.
Ich nehme mich persönlich im übrigen nicht aus. Auch ich hatte ein zweimal kein großes Interesse an einer solchen Diskussion über eine Entscheidung Teil zu nehmen. Halte mich dann aber auch mit Kritik später über die Entscheidung zurück und lebe damit. Immer hin habe ich selbst nichts dazu bei getragen.
Das hat doch mit "entmündigen" nichts zu tun. Ich wollte nur anmerken, dass sich Martin dort bereits geäußert hat, aus meiner Sicht vielleicht nicht deutlich genug.
Wobei ich die Änderung von "critical" auf "low_critical" nicht mal schlecht fände.
ZitatAber anscheinend ist es für ein paar Leute einfacher sich darüber tagelang das ... zu zerreißen wie Kurzsichtig aus deren Sicht gedacht wurde...
Damit kritisierst Du aber nicht DEN Modulautor, sondern mehrere Leute, die sich darüber echauffieren, mich eingeschlossen. Wo aber bitte soll ich mich außern, wenn nicht hier?
Liebe Developer, bitte sorgt dafür dass die Argumente gehört werden. Es ist alles gesagt. Alles weitere liegt nicht mehr in meiner Macht.
Leute Leute, was hier los ist. Ein Problem wurde erkannt und nun geht es daran dies zu lösen. Nicht mehr und nicht weniger. Nix wurde geheim entschieden und niemand vor vollendete Tatsachen gestellt, die sich vor allem nie wieder ändern lassen.
Und @betateilchen: netter Beitrag, vor allem, wenn man bedenkt, dass du im entsprechenden Thread einer der ersten Poster warst. Da verstehe ich deinen Beitrag hier nicht wirklich in dieser Form...
@all: Ich denke die Idee in eine Software wie FHEM gewisse Standards zu bringen ist nicht schlecht und um diese Idee geht es. Daher entspannt euch mal wieder, erkennt den guten Willen und übt konstruktive Kritik. Wir sind nicht bei Logitech und es wurden eben mal aus FHEM alle anderen Systeme spontan ausgesperrt, weil jemand Bock hatte. Und selbst die haben eingelenkt ;)
Außerdem ist noch Weihnachten :)
Zitat von: Amenophis86 am 26 Dezember 2018, 20:01:21
Ein Problem wurde erkannt und nun geht es daran dies zu lösen.
danke, das ist die erste positive nachricht zu diesem thema.
bis vor 3 stunden sah das aber noch völlig anders aus. ;)
Irgendwie muss ich was verpasst haben. Bisher gab es in FHEM eigentlich nur best practice Standards. Das kann man gut finden oder auch nicht. Hat aber bisher einigermaßen funktioniert. Nun scheint es plötzlich so zu sein, dass einzelne User einen Vorschlag für einen neuen Standard machen. Dann diskutieren ein paar Leute darüber, die zufällig den Thread gelesen haben, werden sich einig und schon ist der neue Standard verabschiedet. Und nur weil es im Wiki steht, das auch jeder ändern kann, macht es auch nicht automatisch zu absoluten Wahrheit.
Ich bin in einem Alter, wo ich solche Vorgehnsweisen vermutlich aufgrund beginnendem Altersstarrsinn erst recht ignoriere.
Ich würde es jedoch akzeptieren, wenn es eine Art Kernteam geben würde, das solche Entscheidungen trifft, wie das in vielen großen OpenSource Projekten der Fall ist. Das sollten dann Leute sein, die die Tragweite ihrer Entscheidungen wirklich überblicken.
Nun, wie schon mehrfach erwähnt werde ich mich dem fhem-standart unterordnen und ihn implementieren, so er verabschiedet ist. Ich habe parallel bei Rudi angefragt, wie das so mit "veranschieden von Standards" ist und ob in der developer wiki Ecke jeder einfach einmal einen aufstellen darf.
Das Batterie reading ist nun die Diskussion fast nicht wert, einen workaround gibt es auch. Also alles halb so schlimm.
Dennoch erwarte ich von Rudi und der Kerntruppe ein paar klare Richtlinien welche, wie gesagt unter Abwägung der aktuellen Verbreitung, dem Risiko, der Kompatibilität über die produktfamilien hinweg und der Zukunftsfähigkeit erstellt werden. Keine leichte Aufgabe. Sollte der Beitrag im wiki dies nicht durchlaufen haben ist er noch nicht reif und wird nicht scharf geschaltet.
Die Freiheit von fhem ist gut und innovativ. Allesdings ist es mittlerweile so gross dass Standards klar definiert werden sollten.
Auf der Oberfläche wünsche ich mir, neben "privaten" neuen ideen auch verlässliche standardmodule zur systemwartung und Übersicht. Ein allgemeines "system-health" modul welches mir kurz einen Hinweis auf probleme gibt. Für hm leistet dies hminfo (zustandsübersicht, alarm sammler einstellbar, battery, dead or alive,...) Um das übergreifend zu sinnvoll implementieren braucht es standards.....
Möchte hier auch was dazu sagen:
Zwei Batteriezustände: "low" und "ok" finde ich echt zu wenig.
Die Ide mit
Zitatz.B. 6 level definieren
0: unknown
1: ok
2:future use
3:Device mit 3 Leveln melden "low" mit 3
4:future use
5:schlechtester Level des Device.
ist besser.
Es geht mir hier mehr um die 0-5, als um die Begriffe.
Hoffe es findet sich eine Lösung die für alle ok ist.
Nach Martins letztem Statement im Developer-Forum sehe ich mich - anstelle einer PM - genötigt, leise Einwände zu äußern, die ich aber gleichzeitig zur Diskussion stelle - kann ja sein dass ich falsch liege.
ZitatBatteryLevel hätte man für % lasse können.
batteryLevel ist in CUL_HM eine Spanungsangabe ohne Einheit. Hätte in CUL_HM eine Änderung bewirken müssen.
Aber es soll ja sauberer zwischen batteryPercentage und batteryVoltage unterschieden werden.
ZitatBei manchen der hm devices gibt es ein critical welches unspezifiziert ist. Es sollte nach low kommen. Auch möglich, dass low nicht kommt. Manche devices haben kein critical. Dann gibt es nur low.
Was dann passiert? ... wahrscheinlich ist er bald leer. Im unterschied zu low ist das möglicherweise früher der fall. Was für vorteile der user hat es auszuwerten? ...
Die wenigsten Devices haben "critical". Bei den hier schon zitierten Geräten "Stellantrieb" und "Außensirene" sind damit wohl kritische Zustände gemeint - ein Gerät mit schwachem Batteriezustand wird noch funktionieren, ein Gerät mit kritischem Energiezustand hat vermutlich noch genug Saft, um mit der Zentrale zu kommunizieren, aber eben nicht mehr für den eigentlichen Betrieb - einen Motor zu bewegen oder den Blitzer/Sirene für eine sichere Alarmierung. Da muss der User nicht schneller laufen ;D ;D ;D - die Funktion des Gerätes ist nicht mehr vollständig gegeben. Des Benutzers Erfahrung mag ihm mitteilen, dass eine "low" Battery noch eine Weile funktioniert (SCos laufen bei mir mindestens noch einen Monat, ebenso RT-DN, beim Neigungssensor TIS habe ich erst ein halbes Jahr später die Batterie getauscht, obwohl die Funktion noch gegeben war. ... bei "critical" MUSS der User umgehend handeln.
"dead" hat nur Sinn bei Geräten, die noch kommunizieren können, also etwa in Bezug auf eine Pufferbatterie. Bei reiner Batteriespeisung ist das ganze Gerät "dead" - so wie es der ActionDetector schon jetzt ausweist - hier stimme ich Martin übrigens voll zu, CUL_HM ist hier weit voraus.
Mit "discharge1" etc. kann ich ehrlich GAR NICHTS anfangen. Das assoziiere ich mit der aktuellen Batteriebehandlung durch das Gerät, das ist aber eigentlich kein Thema gewesen. UNd das Mapping von "critical" auf eine andere Wertebezeichnung halte ich schon wieder für eine fragwürdige Interpretation, allenfalls "low_critical" macht für mich Sinn.
ZitatIch haben nun einmal schnell durchgesucht: "battery" wird sehr oft genutzt - batteryState scheint ein Exot gewesen zu sein.
Als Reading hierzu finde ich neben ok und low auch unknown. Scheint sinnvoll.
Auch batteryLevel habe ich gefunden, batteryVoltage allerdings nicht.
=> warum wurden also neue Readigns eingeführt welche noch nicht existierten?
1. Neue Readings heben sich dadurch hervor dass sie neu sind. Man kann sehr gut erkennen, ob die neuen Regeln umgesetzt sind.
2. Neue Namen charakterisieren die Werte besser. Ein Level ist eine allgemeine Höhenangabe, der Bezug ist völlig unklar. Eine Spannung ist eine Spannung (voltage) und eine Prozentangabe eine Percentage. Da muss man nicht mehr rätseln, was was ist. Und "battery" ist ein Oberbegriff für einen Energiespeicher. Wenn man umgangssprachlich meint, dass eine Batterie "ok" ist, dann assoziiert man damit allgemein, dass sie noch genug Saft hat - aber man kann auch damit meinen, dass sie technisch sicher ist, für den Einsatzzweck geeignet ist usw, oder dass ihr Gesamtzustand noch brauchbar ist - etwa eine Lebensalterabschätzung durch Innenwiderstandsmessung, wie sie bei der Pufferakkuüberwachung Standard sein sollte. Das wäre aber eher was für "batteryCondition".
batteryState ist übersetzt "Batteriestatus". Das ist zwar auch etwas allgemein, aber zumindest assoziiert "ok" keinen Handlungsbedarf.
Zitat=> ich habe immer versucht, existierende Readings zu nutzen. Namen und Werte. Jetzt machen wir halt einmal etwas Neues?
Man mag wirklich darüber streiten, ob es Sinn macht, einen weit etablierten Begriff wie "battery" zu ersetzen. Das meint wohl auch Thorsten, wenn er die Beibehaltung der Vorgaben von eQ3 in der XML fordert. Insofern kann man den Schwarzen Peter aber an eQ3 weiterreichen, denn deren Benamung ist in diesen Punkten eben auch nicht eindeutig und daher verbesserungswürdig. Da wir eQ3 nicht beeinflussen können ...
Ich glaube die 3 Seiten hättet ihr euch sparen können. Da der wiki Beitrag so keinen Bestand hat.
Aufgrund der Aussage
Zitat von: Pfriemler am 26 Dezember 2018, 19:04:30
Davon abgesehen war ich überrascht zu sehen, dass meine Batterieüberwachung bei den FHT-Fenstersensoren bereits batteryState erwartet ...
Habe ich auch festgestellt, dass meine Batterieüberwachung seit August nicht mehr funktioniert.
Darauf habe ich im SlowRF nachgefragt, weshalb bei den zugehörigen FHT80 keine Änderung vorgenommen wurde.
Mir wurde von höchster Stelle gesagt,dass es sofort nachgezogen wird, aber battery aufgrund der vielen Abhängigkeiten weiterhin bestehen bleibt.
Jetzt haben mein FHT80 einmal battery und BatteryStatus
https://forum.fhem.de/index.php/topic,94912.0.html
Hallo Pfriemler,
zu BatteryLevel: Zustimmung. CUL_HM müsste ändern. Hatte ich schon erwähnt
ZitatbatteryVoltage: wenn die Spannung ausgegeben wird. CUL_HM müsste ändern.
Dead ist immer noch nicht verstanden. Natürlich meldet nicht das device "ich bin tot". Das ist eine überwachung der Zentrale (Action Detector). Bei CUL_HM realisiert auf 2 Methoden: Devices melden sich regelmäßig. Wenn nicht sind sie tot. Manche (eigentlich fast alle Batterie devices) unterstützen das.
Für andere Devices kann man so etwas erzwingen. FHEM sendet einen StatusRequest (wenn vom Device unterstützt). Sollte das nicht beantwortet werden ist das Device tot.
=> stellt sich die Frage. welche Readings mit "tot" überschrieben werden. Battery wäre in jeden Fall sinnvoll.
Zitat"dead" hat nur Sinn bei Geräten, die noch kommunizieren können, also etwa in Bezug auf eine Pufferbatterie
=> ist also komplett falsch, da das Verfahren damit GARNICHTS zu tun hat.
ZitatMit "discharge1" etc. kann ich ehrlich GAR NICHTS anfangen
Verstehe ich. Sehe ich wie Paul: Die Level sind wichtig, die Namen noch zu finden. Hierbei sollte man erfassen, welcher Level "ok" ist (full, ok), welche warning (low?) und welche kritisch.
Ich will definitiv nicht betrachten, wie, wie lange und was an einem Device noch funktioniert. Das ist dann Sache den Jeweiligen Entwicklers und seiner User. Battery braucht nur die Platform, so etwas auszudrücken. Grundsätzlich ist hier eine Semantik festzulegen.
- devices werden manchmal 2 level unterstützen, manchmal mehr
- wird FHEM hier nur 2 Level haben? Die Info der Devices ist auf 2 zu reduzieren - period?
- es gibt mehr (5?) level. Sind die üblichen dann 3=ok und 4=low, die Anderen sind weitere Verschärfungen?
- es gibt mehr (5?) level. Sind die üblichen dann 1=ok und 5=low, die anderen sind Zwischenschritte?
So etwas ist m.E. einmal grundsätzlich zu definieren und dann sinngemäß durchzuziehen.
Die aktuelle Änderung halte ich für ... mehr als unschön. Weil sich dafür entschieden wurde, die 90% vorhandenen "battery (ok|low)" zu ändern.
Ich verstehe hier nicht, wie mit den User umgegangen wird. Es gibt Bastler welche immer am Ball bleiben. Andere arbeiten sich ein, bauen sich ein system und... nutzen es dann einfach. Ein Reading zu ändern ist "gemein". Sie müssen erst einmal merken, dass es einen Trigger nicht mehr gibt. Wenn wir Battery gegen batterystate tauschen bleibt battery vorhanden. Der User wiegt sich in Sicherheit... bis es kracht.
=> FHEM ist m.E. in seiner Basis aus der Bastelphase entwachsen." Mal schnell ändern" hat Konsequenzen- und muss also einen Grund haben.
Hallo Martin,
Du hast mich teils missverstanden. Wir sind dennoch in vielen Punkten einer Meinung, auch wenn das vielleicht nicht so rüberkam.
1. Du schriebst in Development:
ZitatbatteryLevel: kann man für Prozent einfach lassen. Kein Grund zu ändern
batteryVoltage: wenn die Spannung ausgegeben wird. CUL_HM müsste ändern.
Ich wollte damit sagen: CUL_HM müsste so oder so ändern, weil batteryLevel in CUL_HM auch kein % ist.
2. "dead" ist in CUL_HM derzeit ein Zustand des
Gerätes, festgestellt vom ActionDetector. "dead" hat mit dem
Batteriezustand absolut nichts zu tun, zumal kein mir bekanntes Gerät hier "dead" liefert. Ich halte es nicht für sinnvoll, das von CUL_HM nach "battery[Status]" mappen zu lassen. "dead" werden doch sicher auch alle HM-Geräte automatisch, wenn kein HM-IO mehr funktionsfähig ist (und daher überhaupt keine zyklischen Statusmeldungen mehr in FHEM ankommen) - oder hast Du diesen Fall berücksichtigt? Definitiv fallen Geräte jedenfalls regelmäßig in "dead", wenn es Funkprobleme gibt. Was mit Batterie eben nichts zu tun hat. Punkt.
3. Sind Abstufungen des Batterie(lade)zustandes vorhanden, gehören sie m.M.n. nach "batteryPercent" und nicht nach "battery[State]".
"ok" ist eine Batterie in 70-80% ihrer Laufzeit. Viele Geräte (aus der Nicht-Smarthome-Ära) reklamieren Batterien etwa bei diesem Level als austauschwürdig, nach meinen Erfahrungen und Messungen (habe u.a. Batterien in Messgeräten "restentleert").
Du hast recht, das ist eine Festlegungsfrage - aber sie tritt eh nur auf, wenn das Gerät selbst keinen simplen BatterieStatus liefert, sondern nur eine prozentuale Angabe. Solche Geräte kenne ich jedenfalls nicht.
ZitatDie aktuelle Änderung halte ich für ... mehr als unschön. Weil sich dafür entschieden wurde, die 90% vorhandenen "battery (ok|low)" zu ändern.
Das unterschreib ich, dann argumentier das so an der richtigen Stelle - in Development, im Wiki, in der Wiki-Diskussion, ...?
Vielleicht findest Du mehr Unterstützer dort als Du denkst.
Und vergiss nicht "low_critical" bzw. "critical" ... ;)
Nachtrag: Wir sollten bei der Diskussion immer die Sachen trennen:
1. Wie sollen die Readings künftig heißen (umbenennen, welche beibehalten, ...)
2. Welcher Wertebereich ist sinnvoll, ohne dass signifikante Infos verloren gehen.
3. wie sollte der Übergang gestaltet werden. Dazu gab es zuletzt sinnvolle Einwendungen, feature level betreffend (finde ich).
ZitatWir sind dennoch in vielen Punkten einer Meinung
Sehe ich auch so.
ZitatIch wollte damit sagen: CUL_HM müsste so oder so ändern, weil batteryLevel in CUL_HM auch kein % ist
sagte ich(etwas indirekt) auch schon. Aber erst wenn das Konzept komplett steht. Auch der "State"
Zitat"dead" hat mit dem Batteriezustand absolut nichts zu tun
sehe ich nicht so. Es ist der Zustand nach "low" welcher von der Zentrale festgestellt werden muss. Macht die HMCCU ähnlich. Ist quasi auch so beschrieben.
Wenn die Batterie leer ist bleibt im Reading immernoch "low". Inhaltlich quatsch. Man kann es mit Dead mappen.
ZitatIch halte es nicht für sinnvoll, das von CUL_HM nach "battery[Status]" mappen zu lassen.
ok - bin ich auch vorsichtig. Daher ist es ja auch nicht gemacht (ich denke nicht erst seit jetzt darüber nach :) )
ZitatWas mit Batterie eben nichts zu tun hat.
hier wieder keine Übereinstimmung. Typisch ist es eben schon die Batterie.
Aber: wie man es richtig macht. Mit einem zentralen Alarm-modul. Dieses sollte die kritischen Zustände sammeln und auswerten. Macht eine professionelle bedienfreundliche SW so. Will sagen: unterliegende Alarme (ich rede von Maintenance, interne Alarme) werden nur angezeigt, wenn kein überliegender vorliegt. Wenn also ein IO zu Verfügung steht wird (in der Alarmzentrale) ein Alarm für das IO (in CUL_HM die vccu) angezeigt. "Dead" werden ausgeblendet, ebenso wie rssi -alarme oder protokoll-alarme. Nicht gelöscht, nicht im Device. Aber im Alarm/System-Cockpit.
ZitatSind Abstufungen des Batterie(lade)zustandes vorhanden, gehören sie m.M.n. nach "batteryPercent"
keine Zustimmung. Kann man aber so entschienden.
Zitat"ok" ist eine Batterie in 70-80% ihrer Laufzeit.
verstehe ich nicht.
1) das Device weiss nicht, ob ein Akku oder eine Batterie eingelegt ist.
2) der Level ist viel zu hoch, da ich bei "low" an das tauschen denke. Also sollte "low" bei 10-20% der Kapazität. Ah - hast du das so gemeint?
3) das kommt typisch sowieso aus den Device und kann nicht beeinflusst werden.
Zitatdann argumentier das so an der richtigen Stelle
steht schon drin. Allerdings habe ich viel angeschnitten. Das macht es kompliziert. Ist nur so, dass mir an einigen Stellen die Basis und strikte Führung in FHEM fehlt.
ZitatNachtrag: Wir sollten ...
Zustimmung.
Für mich extrem wichtig: Wann und wie baut jemand ein FHEM-HW-control-center. Also das Teil analog HMInfo welches
- alarme sammelt und darstellt
- eine KURZE! Systemübersicht gibt - was ist aktiv,...
- zwischen Info/Warning/error/critical unterschieden kann
- Alarme Quittieren und ausblenden kann
und das nicht selbst aus den Modulen destiliert sondern die Modulentwickler zwingt, ordentliche und standartisierte Infos breitzustellen
Übrigens werden ich über den Einwürf nach denken, IO Fehler besser darzustellen. Im Device und in HMInfo. Und in den Kanälen.
In meiner Instalation werde ich dann auch die Readings "ausblenden". Hatte es schon zu oft, dass die Power-gierigen Temperatur Sensoren leer waren und das Temp-reading einfach stehen bleibt.
Ich werden es wohl als Attribut anbieten:
attr failReplaceValue: (
no,dead,0,<userdef>)
könnte man in jeder Entity setzen und dann bei "last-IO-OOS" oder Device dead werden die "running parameter" wie temperatur "geklemmt" - oder eben nicht.
Es könnte sein, das "dead" das Ergebnis einer leeren Batterie ist. Wenn wir Erkenntnisse haben. Was ActionDetector aber derzeit einzig aufgrund fehlender Meldungen des Devices - aus welchen Gründen auch immer - annimmt, ist ein "probably dead". Hat es zuvor lange einwandfrei funktioniert und rechtzeitig eine "low"-Warnung gesendet, wird die tote Batterie höchstwahrscheinlich - aber eben nicht sicher - die Ursache sein. Typisch, wie Du sagst.
Was aber nur sicher ist: das Gerät liefert keine Daten. Aber es ist sinnlos, den User zum Batteriewechsel zu schicken, weil das Gerät tatsächlich aus anderen Gründen nicht kommunizieren kann. Wenn also ein AlarmModul/interface dem User das Nichtfunktionieren des Gerätes meldet und gleichzeitig auf den zuvor dagewesenen niedrigen Batteriezustand hinweist, fände ich das ok. Aber ein "dead" aufgrund einer blockierten Kommunikation ist eigentlich nicht hinnehmbar. Hier sind die Grenzen fließend: Schon der sehr temporäre Ausfall eines HM-Interfaces, welches als einziges ein entfernteres Gerät liest, kann dazu führen, dass ActionDetector auf "dead" erkennt. Ich habe das bei den SCos und bei einem Schalterinterface am Briefkasten sehr regelmäßig - bei letzterem auch, weil dort von mir ein falsches Interval eingestellt ist - es reicht schon, dass der Briefkasten einen Tag lang nicht "bedient" wurde (was hier ein halbes Dutzend Mal im Jahr vorkommt) und ein Gerät ist "dead" ... Daher meine Weigerung, beim "anscheinlichen" Ausfall eines Gerätes auf "dead" zu erkennen.
Kurz: "dead"
für ein Batteriereading ohne vorherige Anzeichen von schwacher Batterie ist Quatsch. Mit vorheriger Meldung einer schwachen Batterie bleibt es eine sinnvolle zwar, aber dennoch Vermutung.
Zu Deinem "wie man es richtig macht: " volle Zustimmung.
Zitat2) der Level ist viel zu hoch, da ich bei "low" an das tauschen denke. Also sollte "low" bei 10-20% der Kapazität. Ah - hast du das so gemeint?
Natürlich.
Zitat(Batterie ok) 3) das kommt typisch sowieso aus den Device und kann nicht beeinflusst werden.
Bei Homematic ja. Aber aus der Developer Diskussion entnehme ich, dass es durchaus Geräte zu geben scheint, die
stattdessen ein mehrstufiges Ranking liefern. Diese Details sähe ich lieber in batteryPercentage als in battery(State).
Die Akku/Batterie-Problematik ist eine andere. Viele Geräte können von sich aus nicht mit Akkus umgehen, bei HM ist mir kein Gerät bekannt, dem man das explizit sagen kann. Bei einigen ist es indirekt durch das Setzen der lowBat-Schwelle möglich.
Und Deine Argumentationen ...
Zitatsteht schon drin. Allerdings habe ich viel angeschnitten. Das macht es kompliziert. Ist nur so, dass mir an einigen Stellen die Basis und strikte Führung in FHEM fehlt.
Zustimmung. Aus meiner Sicht gehen Deine/unseren konkreten Vorschläge im Text leider etwas unter. Aus meinen Diskussionserfahrungen ist es sinnvoll, seine Ziele oder Vorschläge gelegentlich, ggf. formulierungsangepasst oder gestrafft, zu wiederholen. Das vermisse ich.
Der Konsenz liegt doch auf der Hand, aber er wird nicht ausgesprochen, schade.
ZitatFür mich extrem wichtig: Wann und wie baut jemand ein FHEM-HW-control-center. Also das Teil analog HMInfo welches
- alarme sammelt und darstellt
- eine KURZE! Systemübersicht gibt - was ist aktiv,...
- zwischen Info/Warning/error/critical unterschieden kann
- Alarme Quittieren und ausblenden kann
und das nicht selbst aus den Modulen destiliert sondern die Modulentwickler zwingt, ordentliche und standartisierte Infos breitzustellen
Hallelujah. Bin ich VOLL dabei.
ZitatHatte es schon zu oft, dass die Power-gierigen Temperatur Sensoren leer waren und das Temp-reading einfach stehen bleibt.
Ähnliche Probleme hatte ich früher mit CUL_WS-Sensoren. Mal kamen die Telegramme alle fünf Minuten, dann stunden- oder tagelang nicht, kein System erkennbar. In der Oberfläche stehen bei mir seit längerem die Zeiten der Werte via stateFormat. Das hilft schonmal. Anderswo wird hier gerade daran gebastelt, wie man solchen Werten eine auffällig andre Farbe verpassen kann. Sinnvolle Infos zur Gültigkeit abseits des Readingsalters würden hier ungemein helfen, Zustimmung.
ZitatEs könnte sein, das "dead" das Ergebnis einer leeren Batterie ist. Wenn wir Erkenntnisse haben. Was ActionDetector aber derzeit einzig aufgrund fehlender Meldungen des Devices - aus welchen Gründen auch immer - annimmt, ist ein "probably dead".
sorry, nur ganz kurz: Hier steige ich aus.
Es ist fast alles nur Probably. Es kann immer auch einen anderen Grund geben. Was willst du sagen, was befürchtet du? Wenn hier "Dead" steht ist erst einmal nichts passiert. Der Anwender weiss, dass sich das Device nicht meldet. Er sollte einmal die batterie tauschen. Wenn das nichts hilft - tauscht er noch einmal und noch einmal... ? Wenn das Device am Display Bat-ok anzeigt, FHEM aber dead dann
1) hat das Device die notwendige Aufmerksamkeit
2) der Anwender die Aufgabe den fehler zu suchen
3) er könnte tagelag die Batterie tauschen und nicht merken, dass es nichts bringt weil das IO kapuut ist. Ich halte auch hart gesottene Anwender für intelligenter. Das passiert nicht.
ZitatDiese Details sähe ich lieber in batteryPercentage als in battery(State).
Percentage sind Prozent. Ich würden keinen String erlauben.
in der Developer-Ecke habe ich eher ein "alarmBattery" reading vorgeschlagen. Battery kann m.E. bleiben wie es ist.
Der Wilduchs an Battery-readings und Schreibweisen sollte begrenzt werden.
ZitatSinnvolle Infos zur Gültigkeit abseits
ich bastle mal... Wird mit Sicherheit abschlatbar. Default abgeschaltet.
Hi Pfriemler, gutes neues Jahr.
Das Attribut readingOnDead habe ich nun für Devices eingebaut.
Funktion/Idee: Wenn ein Device nach "dead" geht kann man Readings entsprechend ändern.
Der Anwender hat die Wahl:
- state nach Dead
- und/oder alle periodischen nummerischen Werte nach "0" (bspw werden dann temperaturen in den Grafiken beeinflusst, also genullt. Ausfall ist sichtbat
- und/oder periodiche string werte nach 'dead'
- und/oder setzen user definierter Readings auf "dead"
- Auch alle Kanäle des Device bearbeiten, gleichen Prinzip
Warum nur Devices? => Channels können nicht dead sein
warum keine weiteren Filter (user readings nach '0' ändern): Irgendwann ist schluss und man muss es mit einem Notify machen
warum keine Behandlung von unerrechbaren Devices (Diskussion bevor: letztes IO ist verstorben): Ungünstig. Evtl ist es nur ein temporärer Ausfall Readings sollten dann nicht verändert werden. Dead ist eine vereinbarte tot-Zeit. Wenn diese nicht eingehalten wird, wird entsprechend alarmiert.
Was ist mit Batterie: Kann man über die Periodischen Readings einbeziehen oder nicht.
Wie wird recovered? Die Strings werden auf "notDead" gesetzt. Es sollte nicht lange dauern, bis sie mit gültigen Werten Überschrieben werden.
Wenn ich keine Beeinflussung will? das Attribut nicht setzen oder auf noChange setzen.
Mir hilft es, falsche weil veraltete Statusanzeigen zu erkennen wenn das Device tot ist.
Hallo Martin,
gleiche Wünsche auch für Dich!
Sehe es mir ab morgen interessiert an, da habe ich endlich mehr Zeit. Bin schon gespannt.
nur noch das:
Zitat von: martinp876 am 30 Dezember 2018, 14:58:01
Percentage sind Prozent. Ich würden keinen String erlauben.
Natürlich nicht, war auch nie so gemeint. Ich dächte eher, dass man (hypothetische) Meldungen eines Gerätes zum Batteriezustand wie "voll, halbvoll, niedrig, kritisch" in batteryState als "ok,ok,low,low_critical" mappen sollte und in batteryPercentage als "100,50,20,10" - etwa. 100 ist voll, 0 ist leer. Und bitte keine Kommastellen ...
Mittlerweile wäre mein Favorit
*Kategorie Alarme
> sind primär für ein SystemInfo-modul gedacht
> sollten eigentlich gebündelt für ein Modul (also alle Devices von CULHM bspw) kommen
> könnten aussehen wie in HMInfo: ok:10,warning:2,error:0,critical:2
- alarmBattery wäre die Meldung aller Batterie Devices aus CUL_HM . Andere Module sollten es auch destilieren
- alarmMotor könnte ein weiterer Alarm sein - für Motoren der RTs bspw
- alarmProtokol auch ein Kandidat
=> BatteryLow wäre eine Warning
Das Modul Info sollt dann die Liste der nicht-ok-devices in Internals darstellen. Hier kann man dann in das Device verzweigen (click geht in Readings nicht)
Im Modul kann man dann weitere readings ansehen. Im Reading "battery" kann man dann etwas freizügiger sein, was die Werte betrofft. Auch eine Erweiterung ist nicht mehr so kritisch.
Zitat von: Pfriemler am 30 Dezember 2018, 14:30:32
Es könnte sein, das "dead" das Ergebnis einer leeren Batterie ist. Wenn wir Erkenntnisse haben. Was ActionDetector aber derzeit einzig aufgrund fehlender Meldungen des Devices - aus welchen Gründen auch immer - annimmt, ist ein "probably dead". Hat es zuvor lange einwandfrei funktioniert und rechtzeitig eine "low"-Warnung gesendet, wird die tote Batterie höchstwahrscheinlich - aber eben nicht sicher - die Ursache sein. Typisch, wie Du sagst.
Dazu eine Anmerkung: Normalerweise bekomme ich von den HM-Sec-RHS ein battery low bevor die sich verabschieden. Wenn es draussen sehr kalt ist, ist es jetzt schon mehrfach vorgekommen, dass das Lüften bei -10°C den RHS den letzten Sargnagel verpasst hat ohne vorher ein battery low zu bekommen. Die waren dann komplett tot und mit frischen Batterien war alles wieder ok.
Jetzt muss ich noch einmal
ZitatNormalerweise bekomme ich von den HM-Sec-RHS ein battery low bevor die sich verabschieden
ich verstehe die bedenken nicht. Ich bin mal ausser Haus. Meine Frau achtet nicht wirklich auf die Batterien "low". Eine Batterie kann versterben, ebenso wie die Elektronik.
Low kann Jahrelang anstehen (wenn man die Nerven hat). Mein HM-PBI-4-FM ist so ein Beispiel. Mittlerweise 4 Jahre - funktioniert prima.
Ja, device klauen oder sterben ist eher selten (gut so)
Ja, bat low kommt typisch vor (bat)dead.
wenn man immer gleich reagiert ( so an zu Hause ist,...) ist das alles nett.
Dead ist schlicht eine Ultimative überwachung. Wenn Device Dead gemeldet wird kann man keine Aussage über die Batterie machen. Es ist zumindest "unknown" - wie alle regelmäßigen Messwerte.
Genau genommen sollten alle Werte ausgeblendet werden, wenn dead.
Bei mir (schlechte Wartung) quittiert die Batterie eines Tempsensors gerne den Betrieb. Der gepeerte RT läuft selbständig weiter. Die Graphen werden weiter geschrieben. Aus meiner Sicht unschön.
Zwischenruf: Meinem Energiemesszwischenstecker habe ich jetzt mal testweise ein "readingOnDead = state,channels" verpasst. "dead" erscheint als Status, wenn ich das Ding nicht benutze. Gut!
Eins weitergedacht: wenn jetzt von einem Gerät der Status "dead" bekannt ist - nimmt autoReadReg darauf Rücksicht? Es hat ja keinen Sinn, Daten von einem Gerät anzufordern, welches offenbar nicht mehr arbeitet ...
nein, autoReadReg nimmt keine Rücksicht.
Ist die Frage, ob es der Aufwand wert ist.
a) well alle Daten vorhanden sind wird sowieso nichts gemacht
b) wenn Register fehlen sollten wird einmal probiert. Es schlägt fehl (nur eine message) - dann wird in 30min wieder probiert. Aufwand gering - und es ist ein Versuch kontakt aufzunehmen
c) wenn der Status unklar ist (eher unwahrscheinlich) ist es wie bei Registern.
Wichtiger würde ich es sehen, wenn das Device nach dead zurück kommt. In einem professionellen System müsste das Device erst einmal frisch eingelesen werden. Dazu ist aber das Protokoll dann doch nicht performat genug.
war etwas zu kurz gedacht von mir ...
Problem: HM-Zwischenstecker wird nur temporär benutzt. autoReadReg vesucht den Status zu ermitteln, alle 30 Minuten, wochenlang. 48 überflüssige Logzeilen pro Tag. Es sollte doch von allein aufgeben ...
Lösung: ist schon vorhanden. 2_ponRestart muss man nur setzen... :)
in solchen Fällen kommt das Gerät ja nicht einfach zurück, sondern sendet eine powerOn-Message. Anders sähe das bei batteriebetriebenen Geräten aus, die man auch mobil nutzt und somit temporär entfernt. Da ist mir aber kein Anwendungsfall denkbar.
ZitatNormalerweise bekomme ich von den HM-Sec-RHS ein battery low bevor die sich verabschieden
Die Dinger verabschieden sich bei mir immer ohne low.