Everspring ST814

Begonnen von peterb, 07 September 2013, 14:59:37

Vorheriges Thema - Nächstes Thema

peterb

Hallo Zusammen,

für den Feuchtigkeits- und Zemperatursensor von Everspring habe ich eine Erweiterung für die 10_Zwave.pm getestet, die soweit ganz gut funktioniert.

Ausgangslage:

Eine Abfrage der Werte (Zwave Klasse 31, Befehl 0x04) fürht zu zwei Telegrammen:

01 0C 00 04 00 06 06 31 05 01 22 00 E7 FF

01 0B 00 04 00 06 05 31 05 05 01 32 F1

Entscheidend sind die bold markierten Werte:

01 bzw. 05 kennzeichnen einen Temperaturwert (01) oder Feuchtigkeitswert (05)

Der nächste Wert ist eine Bitmaske:

22 = 00100010

Die ersten drei Bits (001) = 1 Nachkommastelle Genauigkeit
Die nächsten zwei Bits (00) = Celsius (01 = Fahrenheit)
Die letzten drei Bits (010) = Die Werte stehen in zwei Bytes (oder in einem Byte 001), im Falle des ersten Telgramms 00 E7, im zweiten Telegramm nur ein Byte (32).

Meine Erweiterung der 10_Zwave.pm sieht wie folgt aus, und funktioniert erst mal:

SENSOR_MULTILEVEL      => { id => '31',
   get   => { SensorMultilevel => "04" },
   parse => { "06310501(..)(....)" => 'sprintf("Temperature:%0.1f %s ", '.
                 'hex($2)/(10**int(hex($1)/32)), '.
                 'hex($1)&8 ? "F":"C")',
                "05310505(..)(..)" => 'sprintf("Humidity:%0.1f ", '.
                 'hex($2)/(10**int(hex($1)/32)))'},},

Allerdings weiß ich nicht, wie ich bei der Feuchtigkeit das Prozentzeichen in den Sprintf Ausdruck reinsetzen kann.

Außerdem kann man dummerweise am Sensor zwischen C und F umschalten, also wäre es prime, wenn man FHEM seitig im Falle eines Fahrenheit Wertes automatisch in Celsius umrechnen könnte.

Für Hinweise dankbar

Peter

rudolfkoenig

Danke fuer den Patch.

Habe die Texte etwas abgeaendert, damit zu den anderen Klassen, und zu den anderen Modulen passt: SensorMultilevel -> smStatus, Temperature->temperature, usw.

% wird als %% geschrieben, siehe "man -s 3 printf"

Die Umschaltung von F in C moechte ich erstmal so lassen: Umschaltung ist einfach, und FHEM-Code auch. Die Loesung soll nicht nach FHEM verlagert werden, wenn jemand sich beim Geraete-Fummeln nicht beherrschen kann.

Habe die Doku ergaenzt und eingecheckt.  Testen konnte ich es nicht.

peterb

Der Test war erfolgreich, funktioniert alles so wie es soll. Danke dafür!

Aber bezüglich der F C Umrechnung muss ich noch mal nachfragen. Soweit ich weiß kann man die Tasten am Gerät nicht sperren, also muss ich softwareseitig Fahrenheit Werte abfangen bzw. umrechnen. Wo würde man das am sinnvollsten machen?

Mir fällt ad hoc nur ein Cron Job auf Betriebssystemebene ein, in FHEM bin ich noch nicht so versiert ;)


Gruß

Peter

rudolfkoenig

Eine (von mir praeferierte) nicht-technische Loesung waere den Haushaltsmitgliedern zu erklaeren, den entsprechenden Knopf in Ruhe zu lassen.

Technische Loesungen haengen davon ab was man erreichen will:
- mit userReadings einen weiteren Attribut hizufuegen oder mit stateFormat den Status "richtig" setzen.
- in der .gplot Datei mit einem Ausdruck den Wert umrechnen

peterb

Tja, da ich meine Haushaltsmitglieder kenne, ist das ein eher unpraktischer Weg ;)

userReadings und stateFormat sagen mir jetzt beides nichts. Mit einem Ausdruck in der gPlot hatte ich tatsächlich auch schon geliebäugelt, habe haber nichts zum nachlesen gefunden.

Gibt es ein Beispiel auf das ich zurückgreifen könnte?


Gruß

Peter

simli

Hi,
First of all:  I apologize for posting in English, but it's been a long time since my schooldays and my German is a bit rusty...

The updated code works, but I see one or two problems with it.
- First of all it will not work on negative values. ( Just put the ST814 in the freezer for a couple of minutes, and you will see the problem ;-)
The value is in "two's complement" which means that you have to fiddle around a bit to get the real value when it is a negative number.
- Second the precision is hardcoded to one decimal. But that may not be true (I have another sensor with two decimals in temperature readings). This also makes the two's complement calculation a bit more tricky.

I have had this working for half a year by copying the code from ZWave_ParseMeter($) into my own function for "ZWave_ParseSensorMultilevel($)".  It's a bit big to copy in here as I was ambitious enough to make it show any type of sensorvalue. But the important part is like this:
 ...
 my $data = hex(substr($v3, 0, 2*$size));
  my $datalimit = 2**((8*$size)-1) - 1;
  if ($data > $datalimit) {
    my $datasize = 2**(8*$size);
    $data = $datasize - $data;
    $data = 0 - $data;
  };
  $v3 = $data/$prec;

  return "$txt:$v3 $unit";

Maybe this can get you guys started on writing some better code than I am able to cobble together !


 

peterb

Hi Simli,

I have not put my device into the fridge, so I missed this part :)

Anyway, I am not a programmer I am rather an ambitious try and error user with technical background. So I can't help you with your code. Sorry for that. But I can help testing if that helps.


All the best

Peter




simli

Hi Peter,

Usually I keep the sensor out of the fridge! But I actually tried it today. Had to check if there were something in your code (or in Perl) that took care of the two's complement without me understanding it.

I'm probably in more or less the same category as you when it comes to programming. As it is, my program works but it is kind of bolted on with lots of trial and error...

In addition to the ST814 I also have a FGBS001 (from Fibaro) which is able to read four 1-wire temperature sensors. I have one of those sensors hanging out of a window. So that is were I ran accross the problem with negative numbers. To use this sensor I also hacked around in the code for MULTI_INSTANCE (or MULTI_CHANNEL as it is called now in the code). I upgraded Fhem today to check your code, and I see that my MultiInstance code is not working with the changes that has been done there. Maybe I will have a look at it.

I have been meaning to return my findings to the community, but never got around to it before I saw your code. So my hope was that some of the experts here would see some neat way of tidying up my code...


Simen

simli

Okay, final post tonight - seems like I'm hijacking your thread, Peter...

After re-defining my Fibaro-sensor in the "new correct way" I now have the four temperature readings back without using my own code for "Multi Instance".

So, the built in support for Multi Channel is working fine!

I do however have to use my own code to make Fhem "see" the values from the Fibaro, as the current parsing does not include messages from the Fibaro.

This is an example of the output from the Fibaro:
000400050c600d030331050144000007bd   =>  19,81 C
000400050c600d040431050144000007b0   =>  19,68 C
000400050c600d050531050144000007c3   =>  19,87 C
000400050c600d060631050144ffffffe7   =>  -0.24 C

I'm calling my own function like this:
  SENSOR_MULTILEVEL        => { id => '31',
    get   => { smStatus    => "04" },
    parse => { "..3105(.*)" => 'ZWave_ParseSensorMultilevel($1)' }, },


Simen

rudolfkoenig

Zitat000400050c600d030331050144000007bd => 19,81 C
000400050c600d040431050144000007b0 => 19,68 C
000400050c600d050531050144000007c3 => 19,87 C
000400050c600d060631050144ffffffe7 => -0.24 C
Can you tell me more precisely where these lines come from?
As far as I know the byte before the 3105 specifies the length of the remaining data, which is not the case in this example.

peterb

Hi simli,

don't worry about hijacking as long as it isn't my fridge :)

O.K., back to your values. It seems to me that fibaro broke with the zwave compatability. Let's take a closer look:

0331050144000007bd the values after the 3105 are the interesting ones:

01 means we are measuring temperature

44 is a bitmask:
44 is 01000100 in bin. The first three bits (010) define a precision of two, the next two bits (00) stand for Celsius (01 would be Fahrenheit), and the last three bits telling us that the measured value is three bytes long.

In the plain zwave world the value itself is placed directly after the bitmask. But in your fibaro telegramms there are two trailing 00 hex values prior to your values. Maybe they don't want people using their devices with controller outside of the fibaro world. Just guessing...

07bd in decimal is 1981, with the given precision (2) and the unit (C) we get 19,81°C. Hurra...!

Maybe you can try to modify the parse string from "parse => { "06310501(..)(....)" => 'sprintf()" to something like that:

parse => { "06310501(..)0000(....)" => 'sprintf()

For the sake of completeness: The trailing 06 stands for a temperature device, 05 would be a humidity device. Your fibaro telegramms also mentionend a 03 and a 04. I don't know what this stands for at the moment. But try to omit the first byte for a first check.

Good luck

Peter

 

simli

Hi Peter,

I probably pulled those examples from the logfile or the Event Monitor before I had got the device properly recognized (minus the decoded temperature readings). I just had them in a text-file with my own comments from when I was investigating this half a year ago.

I agree with your ideas about the format, but you are miscalculating the number of bytes for the value. The last three bits are 100, which is 4 decimal. So the value is contained in "00 00 07 bd".
The rest is correct.

But the fun part is if you try to decode my last example: 000400050c600d060631050144ffffffe7
The value part here is "ff ff ff e7" which would normally be 4294967271, which in your calculation would be shown as 42949672,71 C ...

But you have to recognize that the leftmost bit of the four bytes is "1", which makes it a negative number. This is where the two's complement enters. You can probably find much better descriptions of this around the Internet, but what I do is just check for the leftmost byte and if necessary calculate the negative value. (max number contained in 4 bytes is 2^32 -1 = 4294967295. Calculate  4294967295 - 4294967271 = 24. Then make that minus, and divide by the precision as usual and you get -0,24 C )

The other numbers you see are the "channel numbers" in the Multi_channel cofiguration. So this is sensor nr.6.  ( nr1 and 2 are binary switch inputs, and 3,4,5 and 6 are temperature readings )


Simen



simli

Hello Rudolf,

The values are from a "Universal Binary Sensor" from Fibaro. I called it FGBS001 in a previous post, but that is probably just a tag from the store I bought it from. The correct designation seems to be FGBS321 v1.2
It has six channels, where four of them are temperature readings from 1-wire sensors.

Here are some new examples for you. Directly from Fhem this time, and not from my notes...

ZWDongle_0_RAWMSG   000400050c600d03033105014400000501
ZWDongle_0_RAWMSG   000400050c600d0404310501440000070e
ZWDongle_0_RAWMSG    000400050c600d0505310501440000004b
ZWDongle_0_RAWMSG   000400050c600d050531050144ffffffdb
ZWDongle_0_RAWMSG   000400050c600d060631050144000006b0
 
I have not really studied this, but it seems to me like the numbers before "3105" are channel numbers.

The first line is from "sensor 3" and is 12.81 C
Next comes "sensor4" at 18.06 C
Then I have two examples from "sensor 5". One at +0.75 C and the next at -0.37 C
And finally there is "sensor 6" showing 17.12 C

I have played around a bit with my code. Will make another post with that. Note that there is a bug in the description I made for Peter.


Simen

simli

Hello Peter,

you have got me playing around with Fhem again! I have been looking at my modification all weekend.

First I have to admit that my calculations above are wrong. The correct answer is -0.25.  I was using my own notes and fitted the description to that, sorry!

Your solution made me think about this in a new way. Instead of doing everything in a separate subroutine in the way that ZWave_ParseMeter does, I have now reduced my function to just calculating the value. That may make the calling of the function more understandable and logical?

 SENSOR_MULTILEVEL        => { id => '31',
    get   => { smStatus    => "04" },
    parse => { "..310501(..)(.*)" => 'ZWave_ExtractValue("temperature",            $1,$2, ("C"   , "F"               ))',
....


I have commented the code below to make it easier for others to see if I have made more errors ... ;-)
Hope this makes it more understandable than my previous post. I'm also attaching my modified 10_ZWave.pm if someone wants to test it. Note that it contains calls for many types of sensors. I have only tested temperature and humidity. The rest of the definitions have been picked up from various code I have seen, and updated today with more definitions from Google's Open ZWave.  


Simen



sub
ZWave_ExtractValue($$$@)
{
  my ($Txt,$Key,$Value,@Units) = @_;

  # $Key is expected to be one byte
  return if ($Key !~ m/^(..)$/);
  # $Value is expected to be at least one byte
  return if ($Value !~ m/^(..)*$/);
 
  # 1st three bits is precision
  # Shift left five places, then AND with mask "00000111"
  my $Precision = 10**((hex($Key) >> 5) & 0x7);

  # Next two bits defines unit of value
  # Shift left three places, then AND with mask "00000011"
  my $UnitIdx = (hex($Key) >> 3) & 0x3;
  # Fetch Unit from suplied array, or return "undef" if out of bounds
  my $Unit = ($UnitIdx > $#Units ? "undef" : $Units[$UnitIdx]);

  # Final three bits is number of bytes to use from $Value
  # No shift, but AND with mask "00000111"
  my $Size = (hex($Key) >> 0) & 0x7;
 
  # Check that $Value contains enough bytes... Silently ignore if
  # there are more than expected
  return if (length($Value) < $Size * 2);

  # Pick out the right number of bytes (should be all..)
  my $v1 = hex(substr($Value, 0, 2 * $Size));
  # Determine maximum positive value contained in $Size number of bytes
  my $v2 = 2 ** (( 8 * $Size) - 1);
  # ...and maximum value contained in $Size number of bytes
  my $v3 = 2 ** (8 * $Size);
  # If $v1 > $v2 then it is a negative number and needs decoding
  my $v4;
  if ($v1 > $v2) {
    $v4 = -($v3 - $v1);
  }
  # Otherwise use it as it is
  else {
    $v4 = $v1;
  };
  # Then divide by precision
  my $v5 = $v4 / $Precision;

  return "$Txt:$v5 $Unit";
}



peterb

Hi Simen,

I am a liitle bit busy at the moment. Hopefully I can test your code the next weekend.

All the best

Peter

FhemOnSynology

Hallo,

in diesem Thread wurde ja die Ansteuerung des Everspring ST814 Multilevel Sensors ausführlich aus Code-Ebene besprochen.

Als Anfänger bekomme ich es aber trotz intensiver Recherche nicht hin die Werte automatisch abzufragen.

Ich bekomme folgende wake-up Events:
2014-02-12_13:30:34 sensor_temp_humidity_2 wakeup: notification
2014-02-12_14:23:26 sensor_temp_humidity_2 wakeup: notification
2014-02-12_15:16:27 sensor_temp_humidity_2 wakeup: notification
2014-02-12_16:09:28 sensor_temp_humidity_2 wakeup: notification
2014-02-12_17:02:21 sensor_temp_humidity_2 wakeup: notification


Dann habe ich versucht über folgenden Eintrag in der fhem.cfg die Daten direkt nach dem Wakeup abzufragen (siehe vorletzte Zeile):
define sensor_temp_humidity_2 ZWave 0161ec85 2
attr sensor_temp_humidity_2 classes ASSOCIATION BASIC BATTERY CONFIGURATION SENSOR_MULTILEVEL VERSION WAKE_UP
attr sensor_temp_humidity_2 room KiZi
define FileLog_sensor_temp_humidity_2 FileLog /usr/local/FHEM/var/log/sensor_temp_humidity_2-%Y.log sensor_temp_humidity_2
attr FileLog_sensor_temp_humidity_2 logtype text
attr FileLog_sensor_temp_humidity_2 room KiZi
define Sensor_2_Messg_Lg notify sensor_temp_humidity_2:wakeup.* { fhem "get sensor_temp_humidity_2 smStatus" }
attr Sensor_2_Messg_Lg room KiZi


Leider funktioniert das nicht...

Frage 1: Was mache ich falsch?

Und dann habe ich noch eine Besonderheit festgestellt:
Laut Bedienungsanleitung des ST814 werden folgende Klassen unterstützt:
ASSOCIATION BASIC BATTERY CONFIGURATION SENSOR_MULTILEVEL VERSION WAKE_UP

Das autocreate hat aber nach dem Inclusive folgende Klassen angelegt:
SENSOR_MULTILEVEL MULTI_CHANNEL VERSION MANUFACTURER_SPECIFIC ASSOCIATION WAKE_UP BATTERY CONFIGURATION BASIC

Frage 2: Woher kommt der Unterschied?
Frage 3: Spielt die Reihenfolge im "attr" Kommando in der FHEM.cfg eine Rolle?

Mx112

Nutzt Du die aktuelle Version? Sofortige Antwort auf wakeup ist erst kürzlich implementiert worden.

Ich frage mit folgendem DEV meinen Stromzähler ab:
KG.k1.EM.Sicherungskasten:wakeup:.notification get KG.k1.EM.Sicherungskasten config 9

Die Reihenfolge der attr solle egal sein, da hab ich mich noch nie drum gekümmert. Mittlerweile mache ich alles über FHEMWEB - keine Ahnung wo das dann ins cfg geschrieben wird.

Hat das besondere Gründe das du das get in { fhem ""} Format absetzt?

Gruß
Matthias
FHEM 5.5 SVN - FB7390 FRITZ!OS 06.03 - RaspberryPi - Z-Wave - FBDECT

FhemOnSynology

#17
Hallo Matthias,

danke für Deine Antwort.

Update: Ja ich verwende fhem 5.5. Habe die 5.3 über Martin Fischers Paket installiert und dann mit einem "update" auf den neuesten Stand gebracht.

Kann ich das mit DEF ... direkt in die Kommandozeile von FHEM eingeben?

Ich habe das get in die geschweiften Klammern gesetzt, da ich mich an dem 2. Beispiel in der FHEM reference orientiert habe:
http://fhem.de/commandref.html#notify
Update: Ah jetzt habe ich es verstanden: Die geschweiften Klammern heissen, dass der Befehl in PERL ausgeführt werden soll. Das ist ja hier nicht nötig. Ich kann die ganzen Klammern also weglassen und stattdessen schreiben:
define Sensor_2_Messg_Lg notify sensor_temp_humidity_2:wakeup.* get sensor_temp_humidity_2 smStatus

Der Befehl scheint auch irgendwie zu funktionieren, allerdings schreibt er mir die Temperatur in das fhem log und die Humidity in den Sensor Log...
fhem log:
2014.02.12 17:55:14 2: ZWave get sensor_temp_humidity_2 smStatus
2014.02.12 17:55:15 3: get sensor_temp_humidity_2 smStatus : temperature:19.5 C
2014.02.12 17:55:15 3: Sensor_2_Messg_Lg return value: temperature:19.5 C
2014.02.12 18:48:06 2: ZWave get sensor_temp_humidity_2 smStatus
2014.02.12 18:48:07 3: get sensor_temp_humidity_2 smStatus : temperature:19.3 C
2014.02.12 18:48:07 3: Sensor_2_Messg_Lg return value: temperature:19.3 C
2014.02.12 19:40:58 2: ZWave get sensor_temp_humidity_2 smStatus
2014.02.12 19:40:59 3: get sensor_temp_humidity_2 smStatus : temperature:19.1 C
2014.02.12 19:40:59 3: Sensor_2_Messg_Lg return value: temperature:19.1 C
2014.02.12 20:33:50 2: ZWave get sensor_temp_humidity_2 smStatus
2014.02.12 20:33:51 3: get sensor_temp_humidity_2 smStatus : temperature:19.0 C
2014.02.12 20:33:51 3: Sensor_2_Messg_Lg return value: temperature:19.0 C


Sensor log:
2014-02-12_17:55:14 sensor_temp_humidity_2 wakeup: notification
2014-02-12_17:55:16 sensor_temp_humidity_2 humidity: 58 %
2014-02-12_18:48:06 sensor_temp_humidity_2 wakeup: notification
2014-02-12_18:48:08 sensor_temp_humidity_2 humidity: 62 %
2014-02-12_19:40:58 sensor_temp_humidity_2 wakeup: notification
2014-02-12_19:40:59 sensor_temp_humidity_2 humidity: 53 %
2014-02-12_20:33:50 sensor_temp_humidity_2 wakeup: notification
2014-02-12_20:33:51 sensor_temp_humidity_2 humidity: 57 %


Werde mal Dein Beispiel ausprobieren und mich wieder melden.

FhemOnSynology

#18
@Matthias:
Also das mit dem "DEF" funktioniert nicht.

Wenn ich folgendes in die Befehlszeile von FHEM eingebe...
DEV sensor_temp_humidity_4:wakeup:.notification get sensor_temp_humidity_4 smStatus

...dann bekomme ich als Antwort:
Unknown command DEV, try help.

Kannst Du bitte genauer beschreiben, wie Du das genau machst?


@Rudolph König:
Du hattest in einem anderen Post folgendes geschrieben:
Zitat von: rudolfkoenig am 28 Dezember 2013, 17:10:13
...
Weiterhin habe ich ermoglicht, dass man bei einem wakeup: notification per notify an die angeschlossenen Kanaele ein GET (smStatus) senden kann, was sofort abgearbeitet werden sollte, das sollte alle batteriebetriebenen Geraete betreffen.
...

Kannst Du bitte genauer erklären, wie ich das verwende?

Ich habe, wie oben geschrieben folgenden Notify angelegt:
define Sensor_2_Messg_Lg notify sensor_temp_humidity_2:wakeup.* get sensor_temp_humidity_2 smStatus

Das Gerät heisst "sensor_temp_humidity_2". Dem Notify habe ich den willkürlichen Namen "Sensor_2_Messg_Lg" gegeben.

Das fhem.log sagt folgendes:
2014.02.13 12:25:47 5: ZWDongle_Read ZWDongle_3: 00040002028407
2014.02.13 12:25:47 5: ZWDongle_3 dispatch 00040002028407
2014.02.13 12:25:47 4: ZWDongle_3 CMD:APPLICATION_COMMAND_HANDLER ID:02 ARG:028407
2014.02.13 12:25:47 5: Triggering sensor_temp_humidity_2 (1 changes)
2014.02.13 12:25:47 5: Notify loop for sensor_temp_humidity_2 wakeup: notification
2014.02.13 12:25:47 5: Triggering Sensor_2_Messg_Lg
2014.02.13 12:25:47 5: Cmd: >get sensor_temp_humidity_2 smStatus<
2014.02.13 12:25:47 2: ZWave get sensor_temp_humidity_2 smStatus
2014.02.13 12:25:47 5: SW: 010800130202310405d4
2014.02.13 12:25:47 5: ZWDongle/RAW: /060104011301e8
2014.02.13 12:25:47 5: SW: 06
2014.02.13 12:25:47 5: ZWDongle_Read ZWDongle_3: 011301
2014.02.13 12:25:47 5: ZWDongle_3 dispatch 011301
2014.02.13 12:25:47 5: ZWDongle/RAW: /010500130500ec
2014.02.13 12:25:47 5: SW: 06
2014.02.13 12:25:47 5: ZWDongle_Read ZWDongle_3: 00130500
2014.02.13 12:25:47 5: ZWDongle_3 dispatch 00130500
2014.02.13 12:25:47 4: ZWDongle_3 CMD:ZW_SEND_DATA ID:00 ARG:
2014.02.13 12:25:48 5: ZWDongle/RAW: /010c00040002063105012200be5a
2014.02.13 12:25:48 5: SW: 06
2014.02.13 12:25:48 5: ZWDongle_Read ZWDongle_3: 00040002063105012200be
2014.02.13 12:25:48 4: ZWDongle_3 CMD:APPLICATION_COMMAND_HANDLER ID:02 ARG:063105012200be
2014.02.13 12:25:48 5: Triggering sensor_temp_humidity_2 (2 changes)
2014.02.13 12:25:48 3: Sensor_2_Messg_Lg return value: temperature:19.0 C
2014.02.13 12:25:49 5: ZWDongle/RAW: /010b0004000205310505013cfb
2014.02.13 12:25:49 5: SW: 06
2014.02.13 12:25:49 5: ZWDongle_Read ZWDongle_3: 0004000205310505013c
2014.02.13 12:25:49 5: ZWDongle_3 dispatch 0004000205310505013c
2014.02.13 12:25:49 4: ZWDongle_3 CMD:APPLICATION_COMMAND_HANDLER ID:02 ARG:05310505013c
2014.02.13 12:25:49 5: Triggering sensor_temp_humidity_2 (1 changes)
2014.02.13 12:25:49 5: Notify loop for sensor_temp_humidity_2 humidity: 60 %


Der Befehl scheint also zu funktionieren. Ausserdem stehen im Sensor die beiden Readings korrekt drin. Allerdings wird der return value, also die Temperatur, in den fhem log geschrieben und die Humidity in den korrekten Sensor log (habe ich mit "define FileLog_sensor_temp_humidity_2 FileLog /usr/local/FHEM/var/log/sensor_temp_humidity_2-%Y.log sensor_temp_humidity_2" definiert).

Wie erreiche ich, dass
1. Auch die Temperatur im Sensorlog auftaucht?
2. Das Gerät Temperatur und Humidity auch auf der Startseite anzeigt? Das Model "ST814" gibt es leider nicht. Kann ich das anlegen? Hinweis: In FHEMWEB kann ich nur zwischen "Everspring_AN1582" und "Everspring_AN1583" auswählen. Das sind aber schaltbare Steckdosen...

rudolfkoenig

ZitatKannst Du bitte genauer erklären, wie ich das verwende?
Mit dem notify, genauso wie Du es schon machst.

Zitat1. Auch die Temperatur im Sensorlog auftaucht?
FileLog regexp anpassen. Siehe auch Event-Log im Browser.

ZitatDas Gerät Temperatur und Humidity auch auf der Startseite anzeigt?
Ich weiss nicht, was mit der Startseite gemeint ist, vermutlich brauchst Du aber stateFormat.

FhemOnSynology

#20
@Rudolph König

Danke für Deine Hilfe.

Zum Thema Logging:
Ich habe den FileLog jetzt folgendermassen angepasst ("OG_KZ_TF_ST814_2" ist der Name des ST814, "Notify_OG_KZ_TF_ST814_2" ist der Name des Notify):
define FileLog_OG_KZ_TF_ST814_2 FileLog /usr/local/FHEM/var/log/OG_KZ_TF_ST814_2-%Y.log (OG_KZ_TF_ST814_2|Notify_OG_KZ_TF_ST814_2)

Leider funktioniert es immer noch nicht!
UPDATE: Habe gerade festgestellt, dass es für den Sensor, der per autocreate angelegt wurde funktioniert. Bei den beiden manuell angelegten jedoch nicht.
Was macht denn das autocreate noch?

Im fhem log wird folgendes eingetragen:
2014.02.13 15:57:16 3: Notify_OG_KZ_TF_ST814_2 return value: temperature:19.0 C
Im "gewünschten" log "FileLog_OG_KZ_TF_ST814_2" jedoch nur
2014-02-13_15:57:15 OG_KZ_TF_ST814_2 wakeup: notification
2014-02-13_15:57:16 OG_KZ_TF_ST814_2 humidity: 56 %


Im Eventmonitor wird immer noch ein Zwave vorangestellt, was aber hier keine Bedeutung haben sollte, denn das wird für alle Events gemacht und die anderen Logdateien funktionieren auch...

Zum Thema "Anzeige auf der Startseite":
Dein Tip war richtig. Mit einem
attr OG_KZ_TF_ST814_2 stateFormat Temperatur:temperature, Feuchtigkeit:humidity
wird mir jetzt in der Raumübersicht die Temperatur und Luftfeuchtigkeit angezeigt.

Mit Icons wäre es natürlich schöner. Dachte, dass hier das "model" etwas beisteuert, so dass z.B. auch die iPhone App weiss, dass es sich um einen Temperatur und Feuchtigkeitssensor handelt...

rudolfkoenig

ZitatWas macht denn das autocreate noch?

Nichts, nur den regexp des FileLogs richtig setzen.
Das FileLog speichert das, was z.Bsp. auch im EventMonitor sichtbar ist (wobei die Modulangabe wie ZWave im Eventmonitor gedanklich zu streichen ist).


ZitatMit Icons wäre es natürlich schöner.
Dazu gibt es icon und devStateIcon Attribute, mit letzteres kann man sogar je-nach Temperatur andersfarbiges programmieren. Ist aber denkarbeit, und es ist _entweder_ Text _oder_ devStateIcon.

Mx112

Zu dem DEF: Ich mache alles über die Weboberfläche. Wenn Du das notify offen hast und oben auf DEF klickst kommt ein Eingabefeld wo dann die Definition reinkommt. Ich hab mal ein Screenshot drangehängt.

Zur Logfile Definition:
Das Notify braucht/darf nicht in die FileLog Definition. Versuch mal:
define FileLog_OG_KZ_TF_ST814_2 FileLog /usr/local/FHEM/var/log/OG_KZ_TF_ST814_2-%Y.log OG_KZ_TF_ST814_2

Oder über die Weboberfläche im Filelog ebenfalls auf DEF klicken dann muss nur das ins Textfeld:
/usr/local/FHEM/var/log/OG_KZ_TF_ST814_2-%Y.log OG_KZ_TF_ST814_2

Damit sollten erstmal alle readings des Devices im Logfile landen. Auch hier bietet die Weboberfläche eine Möglichkeit reges Parts per Mausklick zu konfigurieren, z.B. um die wakeup Notifications nicht mitzuloggen.
FHEM 5.5 SVN - FB7390 FRITZ!OS 06.03 - RaspberryPi - Z-Wave - FBDECT

FhemOnSynology

#23
@Matthias: Danke für Deine ausführliche Erläuterung. Jetzt habe ich endlich verstanden, wie das mit dem DEF in der Weboberfläche funktioniert.
Allerdings hatte ich die DEF genauso, wie von Dir beschrieben und damit wird ausschliesslich die humidity im Sensorlog geloggt. Die Temperatur wird im Fhemlog geloggt.

@Rudolp:
Habe mir auch den per autocreate angelegten Sensor nochmal angeschaut und festgestellt, dass nach der Aufnahme des Notify in den Sensorlog einmal Temperatur und Humidity, dann nur Humidity und dann nur Temperatur geloggt wurden.

Es funktioniert damit also doch nicht.  :(

Also, wie kommen wir hier zu einer Lösung? Fühle mich kurz davor aber ich bekomme die beiden Loggings einfach nicht zusammen...
Ist es etwa ein Timing Problem? Kommen die beiden Antworten vom Sensor so schnell, dass sie nicht richtig verarbeitet werden?

Hoer noch einmal der Versuch es im Detail zu beschreiben.
Der Eventmonitor zeigt folgendes:
2014-02-13 19:28:44 ZWave OG_KZ_TF_ST814_2 wakeup: notification
2014-02-13 19:28:44 ZWave OG_KZ_TF_ST814_2 temperature: 19.1 C
2014-02-13 19:28:45 ZWave OG_KZ_TF_ST814_2 humidity: 60 %


Der Sensorlog "FileLog_OG_KZ_TF_ST814_2" folgendes:
2014-02-13_19:28:44 OG_KZ_TF_ST814_2 wakeup: notification
2014-02-13_19:28:45 OG_KZ_TF_ST814_2 humidity: 60 %


Und der Fhemlog "fhem-2014-02.log" folgendes:
2014.02.13 19:28:44 2: ZWave get OG_KZ_TF_ST814_2 smStatus
2014.02.13 19:28:44 3: Notify_OG_KZ_TF_ST814_2 return value: temperature:19.1 C


Für mich sieht es also so aus, als ob die Temperatur so schnell kommt, dass Sie nicht in den Sensorlog umgeleitet wird sondern nur im Fhemlog aufgeführt wird... Oder?
Die Readings im Sensor sind aber korrekt...

Mx112

Hast Du dein FileLog DEF geädert?

DEF
/usr/local/FHEM/var/log/OG_KZ_TF_ST814_2-%Y.log OG_KZ_TF_ST814_2:.*
FHEM 5.5 SVN - FB7390 FRITZ!OS 06.03 - RaspberryPi - Z-Wave - FBDECT

FhemOnSynology

Mein Filelog für den Sensor sieht folgendermassen aus:

rudolfkoenig

Bei den gegebenen Event-Monitor, Sensorlog und FileLog Definition ist mir ein Raetsel, wieso die temeprature-Zeile nicht im Sensorlog auftaucht. Ich habe sowas noch nie beobachtet.

Schnell oder langsam ist eigentlich egal, wenn es im Event-Monitor sichtbar ist, dann muesste es auch im Sensorlog auftauchen. Koenntest Du bitte:
- die FileLog definition wie von Mx112 geschrieben aendern
- "attr global mseclog" und "attr global verbose 5" setzen
und Event-Monitor, Fhem-Log bzw. Sensorlog daten hier posten.
Auch wenn es nicht wirklich das Problem beheben sollte, vielleicht taucht dabei was auf, was uns auf eine Idee bringt.

FhemOnSynology

#27
Voilà (Nicht wundern, ich habe die Änderung bei einem anderen Sensor gemacht, der zeitnah aufwachte).

Fhemlog:
2014.02.13 21:21:43.957 5: ZWDongle_Read ZWDongle_3: 00040405028407
2014.02.13 21:21:43.957 5: ZWDongle_3 dispatch 00040405028407
2014.02.13 21:21:43.958 4: ZWDongle_3 CMD:APPLICATION_COMMAND_HANDLER ID:05 ARG:028407
2014.02.13 21:21:43.960 5: Triggering OG_SZ_TF_ST814_5 (1 changes)
2014.02.13 21:21:43.960 5: Notify loop for OG_SZ_TF_ST814_5 wakeup: notification
2014.02.13 21:21:43.961 5: Triggering Notify_OG_SZ_TF_ST814_5
2014.02.13 21:21:43.962 5: Cmd: >get OG_SZ_TF_ST814_5 smStatus<
2014.02.13 21:21:43.963 2: ZWave get OG_SZ_TF_ST814_5 smStatus
2014.02.13 21:21:43.964 5: SW: 010800130502310405d3
2014.02.13 21:21:43.969 5: ZWDongle/RAW: /06
2014.02.13 21:21:43.977 5: ZWDongle/RAW: /0104011301e8
2014.02.13 21:21:43.978 5: SW: 06
2014.02.13 21:21:43.987 5: ZWDongle_Read ZWDongle_3: 011301
2014.02.13 21:21:43.994 5: ZWDongle_3 dispatch 011301
2014.02.13 21:21:43.995 5: ZWDongle/RAW: /010500130500ec
2014.02.13 21:21:43.995 5: SW: 06
2014.02.13 21:21:43.997 5: ZWDongle_Read ZWDongle_3: 00130500
2014.02.13 21:21:43.998 5: ZWDongle_3 dispatch 00130500
2014.02.13 21:21:43.998 4: ZWDongle_3 CMD:ZW_SEND_DATA ID:00 ARG:
2014.02.13 21:21:44.677 5: ZWDongle/RAW: /010c00040005063105012200b152
2014.02.13 21:21:44.678 5: SW: 06
2014.02.13 21:21:44.687 5: ZWDongle_Read ZWDongle_3: 00040005063105012200b1
2014.02.13 21:21:44.687 4: ZWDongle_3 CMD:APPLICATION_COMMAND_HANDLER ID:05 ARG:063105012200b1
2014.02.13 21:21:44.690 5: Triggering OG_SZ_TF_ST814_5 (2 changes)
2014.02.13 21:21:44.691 3: Notify_OG_SZ_TF_ST814_5 return value: temperature:17.7 C
2014.02.13 21:21:45.294 5: ZWDongle/RAW: /010b0004000505310505014181
2014.02.13 21:21:45.294 5: SW: 06
2014.02.13 21:21:45.297 5: ZWDongle_Read ZWDongle_3: 00040005053105050141
2014.02.13 21:21:45.297 5: ZWDongle_3 dispatch 00040005053105050141
2014.02.13 21:21:45.298 4: ZWDongle_3 CMD:APPLICATION_COMMAND_HANDLER ID:05 ARG:053105050141
2014.02.13 21:21:45.301 5: Triggering OG_SZ_TF_ST814_5 (1 changes)
2014.02.13 21:21:45.301 5: Notify loop for OG_SZ_TF_ST814_5 humidity: 65 %


Sensorlog:
2014-02-13_21:21:43 OG_SZ_TF_ST814_5 wakeup: notification
2014-02-13_21:21:45 OG_SZ_TF_ST814_5 humidity: 65 %


Eventmonitor:
2014-02-13 21:21:44.691 ZWave OG_SZ_TF_ST814_5 wakeup: notification
2014-02-13 21:21:44.691 ZWave OG_SZ_TF_ST814_5 temperature: 17.7 C
2014-02-13 21:21:45.303 ZWave OG_SZ_TF_ST814_5 humidity: 65 %


Im Sensorlog steht nur das, was mit "Notify loop for..." im fhemlog steht. Für humidity ist das der Fall, für temperature nicht....

rudolfkoenig

Ich habe die ueble Vermutung, dass es ein FHEM-Bug/Feature/Problem ist. Kannst du bitte dein notify so aendern:
define Notify_OG_SZ_TF_ST814_5 notify OG_SZ_TF_ST814_5:wakeup:.notification { delete $defs{OG_SZ_TF_ST814_5}{INTRIGGER};; fhem "get OG_SZ_TF_ST814_5 smStatus" }

und pruefen ob es was aendert.

FhemOnSynology

Danke Rudolph für Deine Unterstützung.

Nachdem ich das Notify wie von Dir gewünscht habe bekomme ich nun nach dem nächsten wakeup im Sekundentakt Events.
Hier mal der Sensorlog:
2014-02-13_22:14:36 OG_SZ_TF_ST814_5 wakeup: notification
2014-02-13_22:14:37 OG_SZ_TF_ST814_5 wakeup: notification
2014-02-13_22:14:37 OG_SZ_TF_ST814_5 temperature: 17.8 C
2014-02-13_22:14:37 OG_SZ_TF_ST814_5 wakeup: notification
2014-02-13_22:14:37 OG_SZ_TF_ST814_5 temperature: 17.8 C
2014-02-13_22:14:37 OG_SZ_TF_ST814_5 humidity: 66 %
2014-02-13_22:14:38 OG_SZ_TF_ST814_5 wakeup: notification
2014-02-13_22:14:38 OG_SZ_TF_ST814_5 temperature: 17.8 C
2014-02-13_22:14:38 OG_SZ_TF_ST814_5 humidity: 66 %
2014-02-13_22:14:38 OG_SZ_TF_ST814_5 temperature: 17.8 C
2014-02-13_22:14:38 OG_SZ_TF_ST814_5 wakeup: notification
2014-02-13_22:14:38 OG_SZ_TF_ST814_5 temperature: 17.8 C
2014-02-13_22:14:38 OG_SZ_TF_ST814_5 humidity: 66 %
2014-02-13_22:14:38 OG_SZ_TF_ST814_5 temperature: 17.8 C
2014-02-13_22:14:38 OG_SZ_TF_ST814_5 humidity: 66 %
2014-02-13_22:14:39 OG_SZ_TF_ST814_5 wakeup: notification
2014-02-13_22:14:39 OG_SZ_TF_ST814_5 temperature: 17.8 C
2014-02-13_22:14:39 OG_SZ_TF_ST814_5 humidity: 66 %
2014-02-13_22:14:39 OG_SZ_TF_ST814_5 temperature: 17.8 C
2014-02-13_22:14:39 OG_SZ_TF_ST814_5 humidity: 66 %
2014-02-13_22:14:39 OG_SZ_TF_ST814_5 temperature: 17.6 C
2014-02-13_22:14:39 OG_SZ_TF_ST814_5 wakeup: notification
2014-02-13_22:14:39 OG_SZ_TF_ST814_5 temperature: 17.8 C
2014-02-13_22:14:39 OG_SZ_TF_ST814_5 humidity: 66 %
2014-02-13_22:14:39 OG_SZ_TF_ST814_5 temperature: 17.8 C
2014-02-13_22:14:39 OG_SZ_TF_ST814_5 humidity: 66 %
2014-02-13_22:14:39 OG_SZ_TF_ST814_5 temperature: 17.6 C
2014-02-13_22:14:39 OG_SZ_TF_ST814_5 temperature: 17.6 C
2014-02-13_22:14:40 OG_SZ_TF_ST814_5 wakeup: notification
2014-02-13_22:14:40 OG_SZ_TF_ST814_5 temperature: 17.8 C
2014-02-13_22:14:40 OG_SZ_TF_ST814_5 humidity: 66 %
2014-02-13_22:14:40 OG_SZ_TF_ST814_5 temperature: 17.8 C
2014-02-13_22:14:40 OG_SZ_TF_ST814_5 humidity: 66 %
2014-02-13_22:14:40 OG_SZ_TF_ST814_5 temperature: 17.6 C
2014-02-13_22:14:40 OG_SZ_TF_ST814_5 temperature: 17.6 C
2014-02-13_22:14:40 OG_SZ_TF_ST814_5 humidity: 66 %
2014-02-13_22:14:40 OG_SZ_TF_ST814_5 wakeup: notification
2014-02-13_22:14:40 OG_SZ_TF_ST814_5 temperature: 17.8 C
2014-02-13_22:14:40 OG_SZ_TF_ST814_5 humidity: 66 %
2014-02-13_22:14:40 OG_SZ_TF_ST814_5 temperature: 17.8 C
2014-02-13_22:14:40 OG_SZ_TF_ST814_5 humidity: 66 %
2014-02-13_22:14:40 OG_SZ_TF_ST814_5 temperature: 17.6 C
2014-02-13_22:14:40 OG_SZ_TF_ST814_5 temperature: 17.6 C
2014-02-13_22:14:40 OG_SZ_TF_ST814_5 humidity: 66 %
2014-02-13_22:14:40 OG_SZ_TF_ST814_5 temperature: 17.8 C
2014-02-13_22:14:41 OG_SZ_TF_ST814_5 wakeup: notification
2014-02-13_22:14:41 OG_SZ_TF_ST814_5 temperature: 17.8 C
2014-02-13_22:14:41 OG_SZ_TF_ST814_5 humidity: 66 %
2014-02-13_22:14:41 OG_SZ_TF_ST814_5 temperature: 17.8 C
2014-02-13_22:14:41 OG_SZ_TF_ST814_5 humidity: 66 %
2014-02-13_22:14:41 OG_SZ_TF_ST814_5 temperature: 17.6 C
2014-02-13_22:14:41 OG_SZ_TF_ST814_5 temperature: 17.6 C
2014-02-13_22:14:41 OG_SZ_TF_ST814_5 humidity: 66 %
2014-02-13_22:14:41 OG_SZ_TF_ST814_5 temperature: 17.8 C
2014-02-13_22:14:41 OG_SZ_TF_ST814_5 humidity: 66 %
2014-02-13_22:14:41 OG_SZ_TF_ST814_5 wakeup: notification
2014-02-13_22:14:41 OG_SZ_TF_ST814_5 temperature: 17.8 C
2014-02-13_22:14:41 OG_SZ_TF_ST814_5 humidity: 66 %
2014-02-13_22:14:41 OG_SZ_TF_ST814_5 temperature: 17.8 C
2014-02-13_22:14:41 OG_SZ_TF_ST814_5 humidity: 66 %
2014-02-13_22:14:41 OG_SZ_TF_ST814_5 temperature: 17.6 C
2014-02-13_22:14:41 OG_SZ_TF_ST814_5 temperature: 17.6 C
2014-02-13_22:14:41 OG_SZ_TF_ST814_5 humidity: 66 %
2014-02-13_22:14:41 OG_SZ_TF_ST814_5 temperature: 17.8 C
2014-02-13_22:14:41 OG_SZ_TF_ST814_5 humidity: 66 %
2014-02-13_22:14:41 OG_SZ_TF_ST814_5 humidity: 66 %
2014-02-13_22:14:42 OG_SZ_TF_ST814_5 wakeup: notification
2014-02-13_22:14:42 OG_SZ_TF_ST814_5 temperature: 17.8 C
2014-02-13_22:14:42 OG_SZ_TF_ST814_5 humidity: 66 %
2014-02-13_22:14:42 OG_SZ_TF_ST814_5 temperature: 17.8 C
2014-02-13_22:14:42 OG_SZ_TF_ST814_5 humidity: 66 %
2014-02-13_22:14:42 OG_SZ_TF_ST814_5 temperature: 17.6 C
2014-02-13_22:14:42 OG_SZ_TF_ST814_5 temperature: 17.6 C
2014-02-13_22:14:42 OG_SZ_TF_ST814_5 humidity: 66 %
2014-02-13_22:14:42 OG_SZ_TF_ST814_5 temperature: 17.8 C
2014-02-13_22:14:42 OG_SZ_TF_ST814_5 humidity: 66 %
2014-02-13_22:14:42 OG_SZ_TF_ST814_5 humidity: 66 %
2014-02-13_22:14:42 OG_SZ_TF_ST814_5 temperature: 17.8 C


Das Fhemlog sieht so aus (habe das verbose wieder auf 3 zurückgestellt):
2014.02.13 22:14:36 2: ZWave get OG_SZ_TF_ST814_5 smStatus
2014.02.13 22:14:37 2: ZWave get OG_SZ_TF_ST814_5 smStatus
2014.02.13 22:14:37 2: ZWave get OG_SZ_TF_ST814_5 smStatus
2014.02.13 22:14:38 2: ZWave get OG_SZ_TF_ST814_5 smStatus
2014.02.13 22:14:38 2: ZWave get OG_SZ_TF_ST814_5 smStatus
2014.02.13 22:14:39 2: ZWave get OG_SZ_TF_ST814_5 smStatus
2014.02.13 22:14:39 2: ZWave get OG_SZ_TF_ST814_5 smStatus
2014.02.13 22:14:40 2: ZWave get OG_SZ_TF_ST814_5 smStatus
2014.02.13 22:14:40 2: ZWave get OG_SZ_TF_ST814_5 smStatus
2014.02.13 22:14:41 2: ZWave get OG_SZ_TF_ST814_5 smStatus
2014.02.13 22:14:41 2: ZWave get OG_SZ_TF_ST814_5 smStatus
2014.02.13 22:14:42 2: ZWave get OG_SZ_TF_ST814_5 smStatus
2014.02.13 22:14:43 2: ZWave get OG_SZ_TF_ST814_5 smStatus
2014.02.13 22:14:45 2: ZWave get OG_SZ_TF_ST814_5 smStatus
2014.02.13 22:14:45 2: ZWave get OG_SZ_TF_ST814_5 smStatus
2014.02.13 22:14:46 2: ZWave get OG_SZ_TF_ST814_5 smStatus
2014.02.13 22:14:46 2: ZWave get OG_SZ_TF_ST814_5 smStatus
2014.02.13 22:14:47 2: ZWave get OG_SZ_TF_ST814_5 smStatus
2014.02.13 22:14:47 2: ZWave get OG_SZ_TF_ST814_5 smStatus
2014.02.13 22:14:48 2: ZWave get OG_SZ_TF_ST814_5 smStatus
2014.02.13 22:14:49 2: ZWave get OG_SZ_TF_ST814_5 smStatus
2014.02.13 22:14:49 2: ZWave get OG_SZ_TF_ST814_5 smStatus
2014.02.13 22:14:50 2: ZWave get OG_SZ_TF_ST814_5 smStatus
2014.02.13 22:14:50 2: ZWave get OG_SZ_TF_ST814_5 smStatus
2014.02.13 22:14:51 2: ZWDongle_3 ERROR: SEND_DATA returned 01
2014.02.13 22:14:51 2: ZWave get OG_SZ_TF_ST814_5 smStatus
2014.02.13 22:14:52 2: ZWave get OG_SZ_TF_ST814_5 smStatus
2014.02.13 22:14:53 2: ZWave get OG_SZ_TF_ST814_5 smStatus
2014.02.13 22:14:53 2: ZWave get OG_SZ_TF_ST814_5 smStatus


Der Eventmonitor ist leer.

rudolfkoenig

Bitte noch eine Runde drehen mit
define Notify_OG_SZ_TF_ST814_5 notify OG_SZ_TF_ST814_5:wakeup:.notification sleep 0.01;; get OG_SZ_TF_ST814_5 smStatus

FhemOnSynology

#31
@Rudolph: Hier die Ergebnisse:

Eventmonitor:
Events:
2014-02-14 11:28:06.100 ZWave OG_SZ_TF_ST814_5 wakeup: notification


Sensorlog:
2014-02-14_11:28:06 OG_SZ_TF_ST814_5 wakeup: notification

Fhem.log
2014.02.14 11:28:06.083 5: ZWDongle/RAW: /01080004040502840773
2014.02.14 11:28:06.083 5: SW: 06
2014.02.14 11:28:06.093 5: ZWDongle_Read ZWDongle_3: 00040405028407
2014.02.14 11:28:06.093 5: ZWDongle_3 dispatch 00040405028407
2014.02.14 11:28:06.094 4: ZWDongle_3 CMD:APPLICATION_COMMAND_HANDLER ID:05 ARG:028407
2014.02.14 11:28:06.095 5: Triggering OG_SZ_TF_ST814_5 (1 changes)
2014.02.14 11:28:06.095 5: Notify loop for OG_SZ_TF_ST814_5 wakeup: notification
2014.02.14 11:28:06.098 5: Triggering Notify_OG_SZ_TF_ST814_5
2014.02.14 11:28:06.099 5: Cmd: >sleep 0.01;get OG_SZ_TF_ST814_5 smStatus<
2014.02.14 11:28:06.100 3: Notify_OG_SZ_TF_ST814_5 return value: Cannot interpret 0.01;get as seconds


Die Readings des Sensors werden NICHT aktualisiert!

Ich hatte die Idee mit dem Sleep auch schon. Allerdings dachte ich, dass sleep nur in Perl ausgeführt werden kann (mit ganzen Sekunden) und hatte daher folgendes Notify versucht:
define Notify_OG_SZ_TF_ST814_5 notify OG_SZ_TF_ST814_5:wakeup:.notification { sleep(2);;fhem "get OG_SZ_TF_ST814_5 smStatus" }

Das führte aber dazu, dass fhem das get Kommando bis zum nächsten Wakeup verzögert hat und das obwohl der ST814 nach einem wakeup 10 Sekunden aktiv ist...

Update: Sehe gerade, dass es auch "usleep" in Perl gibt für ein sleep in Millisekunden. Ich versuche mal damit...

rudolfkoenig

1. das FHEM sleep Kommando blockiert FHEM nicht, im Gegensatz zum Perl sleep Kommando, ist im commandref dokumentiert.
2. Falls man die Aenderungen im Frontend macht, dann reicht ein ";", in der FHEMWEB Detailansicht, DEF Zeile darf nur noch ein ; vorkommen. Ich bin von der Eingabe in der Kommandozeile ausgegangen (FHEMWEB oder telnet ist egal), da braucht man zwei ;;

FhemOnSynology

Also usleep kann man nicht so einfach ausführen, das müsste man erst definieren...
Ich habe aber eine Alternative gefunden (siehe auch hier http://stackoverflow.com/questions/896904/how-do-i-sleep-for-a-millisecond-in-perl:
define Notify_OG_SZ_TF_ST814_5 notify OG_SZ_TF_ST814_5:wakeup:.notification { select(undef, undef, undef, 0.01);;;;fhem "get OG_SZ_TF_ST814_5 smStatus" }

Leider hat das nicht geholfen. Hier das fhemlog
2014.02.14 13:14:09.756 5: ZWDongle/RAW: /01080004040502840773
2014.02.14 13:14:09.756 5: SW: 06
2014.02.14 13:14:09.766 5: ZWDongle_Read ZWDongle_3: 00040405028407
2014.02.14 13:14:09.767 5: ZWDongle_3 dispatch 00040405028407
2014.02.14 13:14:09.767 4: ZWDongle_3 CMD:APPLICATION_COMMAND_HANDLER ID:05 ARG:028407
2014.02.14 13:14:09.769 5: Triggering OG_SZ_TF_ST814_5 (1 changes)
2014.02.14 13:14:09.769 5: Notify loop for OG_SZ_TF_ST814_5 wakeup: notification
2014.02.14 13:14:09.772 5: Triggering Notify_OG_SZ_TF_ST814_5
2014.02.14 13:14:09.773 5: Cmd: >{ select(undef, undef, undef, 0.01);;fhem "get OG_SZ_TF_ST814_5 smStatus" }<
2014.02.14 13:14:09.806 5: Cmd: >get OG_SZ_TF_ST814_5 smStatus<
2014.02.14 13:14:09.807 2: ZWave get OG_SZ_TF_ST814_5 smStatus
2014.02.14 13:14:09.808 5: SW: 010800130502310405d3
2014.02.14 13:14:09.816 5: ZWDongle/RAW: /060104011301e8
2014.02.14 13:14:09.816 5: SW: 06
2014.02.14 13:14:09.826 5: ZWDongle_Read ZWDongle_3: 011301
2014.02.14 13:14:09.826 5: ZWDongle_3 dispatch 011301
2014.02.14 13:14:09.827 5: ZWDongle/RAW: /010500130500ec
2014.02.14 13:14:09.827 5: SW: 06
2014.02.14 13:14:09.836 5: ZWDongle_Read ZWDongle_3: 00130500
2014.02.14 13:14:09.836 5: ZWDongle_3 dispatch 00130500
2014.02.14 13:14:09.837 4: ZWDongle_3 CMD:ZW_SEND_DATA ID:00 ARG:
2014.02.14 13:14:10.466 5: ZWDongle/RAW: /010c00040005063105012200bd5e
2014.02.14 13:14:10.466 5: SW: 06
2014.02.14 13:14:10.476 5: ZWDongle_Read ZWDongle_3: 00040005063105012200bd
2014.02.14 13:14:10.476 4: ZWDongle_3 CMD:APPLICATION_COMMAND_HANDLER ID:05 ARG:063105012200bd
2014.02.14 13:14:10.479 5: Triggering OG_SZ_TF_ST814_5 (2 changes)
2014.02.14 13:14:10.479 3: get OG_SZ_TF_ST814_5 smStatus : temperature:18.9 C
2014.02.14 13:14:10.480 3: Notify_OG_SZ_TF_ST814_5 return value: temperature:18.9 C
2014.02.14 13:14:11.076 5: ZWDongle/RAW: /010b00040005053105050133f3
2014.02.14 13:14:11.076 5: SW: 06
2014.02.14 13:14:11.086 5: ZWDongle_Read ZWDongle_3: 00040005053105050133
2014.02.14 13:14:11.086 5: ZWDongle_3 dispatch 00040005053105050133
2014.02.14 13:14:11.087 4: ZWDongle_3 CMD:APPLICATION_COMMAND_HANDLER ID:05 ARG:053105050133
2014.02.14 13:14:11.089 5: Triggering OG_SZ_TF_ST814_5 (1 changes)
2014.02.14 13:14:11.089 5: Notify loop for OG_SZ_TF_ST814_5 humidity: 51 %


Evtl. reichen ja auch 10 millisekunden nicht... Soll ich mal 100 versuchen?

FhemOnSynology

Zitat von: rudolfkoenig am 14 Februar 2014, 13:20:17
1. das FHEM sleep Kommando blockiert FHEM nicht, im Gegensatz zum Perl sleep Kommando, ist im commandref dokumentiert.
2. Falls man die Aenderungen im Frontend macht, dann reicht ein ";", in der FHEMWEB Detailansicht, DEF Zeile darf nur noch ein ; vorkommen. Ich bin von der Eingabe in der Kommandozeile ausgegangen (FHEMWEB oder telnet ist egal), da braucht man zwei ;;

Ah ok, aber dann dürfte am Anfang des Ausdrucks keine geschweifte Klammer stehen. Richtig?
Mit geschweifter Klammer kam eben die Fehlermeldung.

Ich versuche mal ohne Klammer.

FhemOnSynology

Hier die Ergebnisse von 2 Sensoren nach 2 wakeups.

Notifys:
define Notify_OG_SZ_TF_ST814_5 notify OG_SZ_TF_ST814_5:wakeup:.notification sleep 0.01;;get OG_SZ_TF_ST814_5 smStatus
define Notify_UG_K1_TF_ST814_4 notify UG_K1_TF_ST814_4:wakeup.* sleep 0.1;;get UG_K1_TF_ST814_4 smStatus


Events:
2014-02-14 14:07:02.738 ZWave OG_SZ_TF_ST814_5 wakeup: notification
2014-02-14 14:07:03.663 ZWave OG_SZ_TF_ST814_5 temperature: 18.9 C
2014-02-14 14:07:03.803 ZWave OG_SZ_TF_ST814_5 temperature: 18.9 C
2014-02-14 14:07:04.233 ZWave OG_SZ_TF_ST814_5 humidity: 46 %
2014-02-14 14:07:04.233 ZWave OG_SZ_TF_ST814_5 dewpoint: 7.0
2014-02-14 14:10:42.546 ZWave UG_K1_TF_ST814_4 wakeup: notification
2014-02-14 14:10:43.363 ZWave UG_K1_TF_ST814_4 temperature: 12.3 C
2014-02-14 14:10:43.476 ZWave UG_K1_TF_ST814_4 temperature: 12.3 C
2014-02-14 14:10:43.975 ZWave UG_K1_TF_ST814_4 humidity: 66 %
2014-02-14 14:10:43.975 ZWave UG_K1_TF_ST814_4 dewpoint: 6.1
2014-02-14 14:10:44.044 ZWave UG_K1_TF_ST814_4 humidity: 66 %
2014-02-14 14:10:44.044 ZWave UG_K1_TF_ST814_4 dewpoint: 6.1
2014-02-14 14:10:44.104 ZWave UG_K1_TF_ST814_4 humidity: 66 %
2014-02-14 14:10:44.104 ZWave UG_K1_TF_ST814_4 dewpoint: 6.1
2014-02-14 14:59:56.604 ZWave OG_SZ_TF_ST814_5 temperature: 18.9 C
2014-02-14 14:59:56.645 ZWave OG_SZ_TF_ST814_5 temperature: 18.9 C
2014-02-14 14:59:57.185 ZWave OG_SZ_TF_ST814_5 humidity: 51 %
2014-02-14 14:59:57.185 ZWave OG_SZ_TF_ST814_5 dewpoint: 8.6
2014-02-14 14:59:57.245 ZWave OG_SZ_TF_ST814_5 humidity: 51 %
2014-02-14 14:59:57.245 ZWave OG_SZ_TF_ST814_5 dewpoint: 8.6
2014-02-14 14:59:57.315 ZWave OG_SZ_TF_ST814_5 humidity: 51 %
2014-02-14 14:59:57.315 ZWave OG_SZ_TF_ST814_5 dewpoint: 8.6
2014-02-14 15:03:35.206 ZWave UG_K1_TF_ST814_4 wakeup: notification
2014-02-14 15:03:36.024 ZWave UG_K1_TF_ST814_4 temperature: 12.2 C
2014-02-14 15:03:36.636 ZWave UG_K1_TF_ST814_4 humidity: 65 %
2014-02-14 15:03:36.636 ZWave UG_K1_TF_ST814_4 dewpoint: 5.8
2014-02-14 15:03:36.695 ZWave UG_K1_TF_ST814_4 humidity: 65 %
2014-02-14 15:03:36.695 ZWave UG_K1_TF_ST814_4 dewpoint: 5.8
2014-02-14 15:03:36.765 ZWave UG_K1_TF_ST814_4 humidity: 65 %
2014-02-14 15:03:36.765 ZWave UG_K1_TF_ST814_4 dewpoint: 5.8


Sensorlogs:
2014-02-14_14:07:02 OG_SZ_TF_ST814_5 wakeup: notification
2014-02-14_14:07:03 OG_SZ_TF_ST814_5 temperature: 18.9 C
2014-02-14_14:07:03 OG_SZ_TF_ST814_5 temperature: 18.9 C
2014-02-14_14:07:04 OG_SZ_TF_ST814_5 humidity: 46 %
2014-02-14_14:07:04 OG_SZ_TF_ST814_5 dewpoint: 7.0
2014-02-14_14:59:55 OG_SZ_TF_ST814_5 wakeup: notification
2014-02-14_14:59:56 OG_SZ_TF_ST814_5 temperature: 18.9 C
2014-02-14_14:59:56 OG_SZ_TF_ST814_5 temperature: 18.9 C
2014-02-14_14:59:57 OG_SZ_TF_ST814_5 humidity: 51 %
2014-02-14_14:59:57 OG_SZ_TF_ST814_5 dewpoint: 8.6
2014-02-14_14:59:57 OG_SZ_TF_ST814_5 humidity: 51 %
2014-02-14_14:59:57 OG_SZ_TF_ST814_5 dewpoint: 8.6
2014-02-14_14:59:57 OG_SZ_TF_ST814_5 humidity: 51 %
2014-02-14_14:59:57 OG_SZ_TF_ST814_5 dewpoint: 8.6
2014-02-14_14:10:42 UG_K1_TF_ST814_4 wakeup: notification
2014-02-14_14:10:43 UG_K1_TF_ST814_4 temperature: 12.3 C
2014-02-14_14:10:43 UG_K1_TF_ST814_4 temperature: 12.3 C
2014-02-14_14:10:43 UG_K1_TF_ST814_4 humidity: 66 %
2014-02-14_14:10:43 UG_K1_TF_ST814_4 dewpoint: 6.1
2014-02-14_14:10:44 UG_K1_TF_ST814_4 humidity: 66 %
2014-02-14_14:10:44 UG_K1_TF_ST814_4 dewpoint: 6.1
2014-02-14_14:10:44 UG_K1_TF_ST814_4 humidity: 66 %
2014-02-14_14:10:44 UG_K1_TF_ST814_4 dewpoint: 6.1
2014-02-14_15:03:35 UG_K1_TF_ST814_4 wakeup: notification
2014-02-14_15:03:36 UG_K1_TF_ST814_4 temperature: 12.2 C
2014-02-14_15:03:36 UG_K1_TF_ST814_4 humidity: 65 %
2014-02-14_15:03:36 UG_K1_TF_ST814_4 dewpoint: 5.8
2014-02-14_15:03:36 UG_K1_TF_ST814_4 humidity: 65 %
2014-02-14_15:03:36 UG_K1_TF_ST814_4 dewpoint: 5.8
2014-02-14_15:03:36 UG_K1_TF_ST814_4 humidity: 65 %
2014-02-14_15:03:36 UG_K1_TF_ST814_4 dewpoint: 5.8


Fhemlog (für den jeweils ersten wakeup der beiden Sensoren):
2014.02.14 14:07:02.708 5: ZWDongle/RAW: /01080004040502840773
2014.02.14 14:07:02.708 5: SW: 06
2014.02.14 14:07:02.717 5: ZWDongle_Read ZWDongle_3: 00040405028407
2014.02.14 14:07:02.718 5: ZWDongle_3 dispatch 00040405028407
2014.02.14 14:07:02.718 4: ZWDongle_3 CMD:APPLICATION_COMMAND_HANDLER ID:05 ARG:028407
2014.02.14 14:07:02.720 5: Triggering OG_SZ_TF_ST814_5 (1 changes)
2014.02.14 14:07:02.720 5: Notify loop for OG_SZ_TF_ST814_5 wakeup: notification
2014.02.14 14:07:02.736 5: Triggering Notify_OG_SZ_TF_ST814_5
2014.02.14 14:07:02.737 5: Cmd: >sleep 0.01<
2014.02.14 14:07:02.738 4: sleeping for 0.01
2014.02.14 14:07:02.758 5: Cmd: >get OG_SZ_TF_ST814_5 smStatus<
2014.02.14 14:07:02.759 2: ZWave get OG_SZ_TF_ST814_5 smStatus
2014.02.14 14:07:02.759 5: SW: 010800130502310405d3
2014.02.14 14:07:02.767 5: ZWDongle/RAW: /060104011301e8
2014.02.14 14:07:02.768 5: SW: 06
2014.02.14 14:07:02.777 5: ZWDongle_Read ZWDongle_3: 011301
2014.02.14 14:07:02.778 5: ZWDongle_3 dispatch 011301
2014.02.14 14:07:02.917 5: ZWDongle/RAW: /010500130500ec
2014.02.14 14:07:02.918 5: SW: 06
2014.02.14 14:07:02.927 5: ZWDongle_Read ZWDongle_3: 00130500
2014.02.14 14:07:02.928 5: ZWDongle_3 dispatch 00130500
2014.02.14 14:07:02.928 4: ZWDongle_3 CMD:ZW_SEND_DATA ID:00 ARG:
2014.02.14 14:07:03.647 5: ZWDongle/RAW: /010c00040005063105012200bd5e
2014.02.14 14:07:03.648 5: SW: 06
2014.02.14 14:07:03.657 5: ZWDongle_Read ZWDongle_3: 00040005063105012200bd
2014.02.14 14:07:03.658 4: ZWDongle_3 CMD:APPLICATION_COMMAND_HANDLER ID:05 ARG:063105012200bd
2014.02.14 14:07:03.660 5: Triggering OG_SZ_TF_ST814_5 (1 changes)
2014.02.14 14:07:03.661 5: Notify loop for OG_SZ_TF_ST814_5 temperature: 18.9 C
2014.02.14 14:07:03.663 2: After sleep: temperature:18.9 C
2014.02.14 14:07:03.788 5: ZWDongle/RAW: /010c00040005063105012200bd5e
2014.02.14 14:07:03.788 5: SW: 06
2014.02.14 14:07:03.797 5: ZWDongle_Read ZWDongle_3: 00040005063105012200bd
2014.02.14 14:07:03.798 5: ZWDongle_3 dispatch 00040005063105012200bd
2014.02.14 14:07:03.798 4: ZWDongle_3 CMD:APPLICATION_COMMAND_HANDLER ID:05 ARG:063105012200bd
2014.02.14 14:07:03.801 5: Triggering OG_SZ_TF_ST814_5 (1 changes)
2014.02.14 14:07:03.801 5: Notify loop for OG_SZ_TF_ST814_5 temperature: 18.9 C
2014.02.14 14:07:04.218 5: ZWDongle/RAW: /010b0004000505310505012eee
2014.02.14 14:07:04.218 5: SW: 06
2014.02.14 14:07:04.227 5: ZWDongle_Read ZWDongle_3: 0004000505310505012e
2014.02.14 14:07:04.228 5: ZWDongle_3 dispatch 0004000505310505012e
2014.02.14 14:07:04.228 4: ZWDongle_3 CMD:APPLICATION_COMMAND_HANDLER ID:05 ARG:05310505012e
2014.02.14 14:07:04.231 5: Triggering OG_SZ_TF_ST814_5 (1 changes)
2014.02.14 14:07:04.231 5: Notify loop for OG_SZ_TF_ST814_5 humidity: 46 %
2014.02.14 14:10:42.518 5: ZWDongle/RAW: /01080004000402840776
2014.02.14 14:10:42.518 5: SW: 06
2014.02.14 14:10:42.527 5: ZWDongle_Read ZWDongle_3: 00040004028407
2014.02.14 14:10:42.528 5: ZWDongle_3 dispatch 00040004028407
2014.02.14 14:10:42.528 4: ZWDongle_3 CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:028407
2014.02.14 14:10:42.530 5: Triggering UG_K1_TF_ST814_4 (1 changes)
2014.02.14 14:10:42.530 5: Notify loop for UG_K1_TF_ST814_4 wakeup: notification
2014.02.14 14:10:42.544 5: Triggering Notify_UG_K1_TF_ST814_4
2014.02.14 14:10:42.545 5: Cmd: >sleep 0.1<
2014.02.14 14:10:42.545 4: sleeping for 0.1
2014.02.14 14:10:42.649 5: Cmd: >get UG_K1_TF_ST814_4 smStatus<
2014.02.14 14:10:42.650 2: ZWave get UG_K1_TF_ST814_4 smStatus
2014.02.14 14:10:42.650 5: SW: 010800130402310405d2
2014.02.14 14:10:42.658 5: ZWDongle/RAW: /060104011301e8
2014.02.14 14:10:42.658 5: SW: 06
2014.02.14 14:10:42.667 5: ZWDongle_Read ZWDongle_3: 011301
2014.02.14 14:10:42.668 5: ZWDongle_3 dispatch 011301
2014.02.14 14:10:42.669 5: ZWDongle/RAW: /010500130500ec
2014.02.14 14:10:42.669 5: SW: 06
2014.02.14 14:10:42.677 5: ZWDongle_Read ZWDongle_3: 00130500
2014.02.14 14:10:42.678 5: ZWDongle_3 dispatch 00130500
2014.02.14 14:10:42.678 4: ZWDongle_3 CMD:ZW_SEND_DATA ID:00 ARG:
2014.02.14 14:10:43.347 5: ZWDongle/RAW: /010c000400040631050122007b99
2014.02.14 14:10:43.348 5: SW: 06
2014.02.14 14:10:43.357 5: ZWDongle_Read ZWDongle_3: 000400040631050122007b
2014.02.14 14:10:43.358 4: ZWDongle_3 CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0631050122007b
2014.02.14 14:10:43.360 5: Triggering UG_K1_TF_ST814_4 (1 changes)
2014.02.14 14:10:43.360 5: Notify loop for UG_K1_TF_ST814_4 temperature: 12.3 C
2014.02.14 14:10:43.363 2: After sleep: temperature:12.3 C
2014.02.14 14:10:43.458 5: ZWDongle/RAW: /010c000400040631050122007b99
2014.02.14 14:10:43.458 5: SW: 06
2014.02.14 14:10:43.470 5: ZWDongle_Read ZWDongle_3: 000400040631050122007b
2014.02.14 14:10:43.470 5: ZWDongle_3 dispatch 000400040631050122007b
2014.02.14 14:10:43.471 4: ZWDongle_3 CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0631050122007b
2014.02.14 14:10:43.473 5: Triggering UG_K1_TF_ST814_4 (1 changes)
2014.02.14 14:10:43.474 5: Notify loop for UG_K1_TF_ST814_4 temperature: 12.3 C
2014.02.14 14:10:43.958 5: ZWDongle/RAW: /010b0004000405310505014283
2014.02.14 14:10:43.958 5: SW: 06
2014.02.14 14:10:43.968 5: ZWDongle_Read ZWDongle_3: 00040004053105050142
2014.02.14 14:10:43.969 5: ZWDongle_3 dispatch 00040004053105050142
2014.02.14 14:10:43.969 4: ZWDongle_3 CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:053105050142
2014.02.14 14:10:43.972 5: Triggering UG_K1_TF_ST814_4 (1 changes)
2014.02.14 14:10:43.972 5: Notify loop for UG_K1_TF_ST814_4 humidity: 66 %
2014.02.14 14:10:44.028 5: ZWDongle/RAW: /010b0004000405310505014283
2014.02.14 14:10:44.028 5: SW: 06
2014.02.14 14:10:44.037 5: ZWDongle_Read ZWDongle_3: 00040004053105050142
2014.02.14 14:10:44.038 5: ZWDongle_3 dispatch 00040004053105050142
2014.02.14 14:10:44.038 4: ZWDongle_3 CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:053105050142
2014.02.14 14:10:44.041 5: Triggering UG_K1_TF_ST814_4 (1 changes)
2014.02.14 14:10:44.041 5: Notify loop for UG_K1_TF_ST814_4 humidity: 66 %
2014.02.14 14:10:44.088 5: ZWDongle/RAW: /010b0004000405310505014283
2014.02.14 14:10:44.089 5: SW: 06
2014.02.14 14:10:44.097 5: ZWDongle_Read ZWDongle_3: 00040004053105050142
2014.02.14 14:10:44.098 5: ZWDongle_3 dispatch 00040004053105050142
2014.02.14 14:10:44.099 4: ZWDongle_3 CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:053105050142
2014.02.14 14:10:44.101 5: Triggering UG_K1_TF_ST814_4 (1 changes)
2014.02.14 14:10:44.101 5: Notify loop for UG_K1_TF_ST814_4 humidity: 66 %


Mein Fazit: Das sleep wird ausgeführt und die Temperatur schafft es jetzt auch in das Sensorlog. Dabei scheint es egal zu sein, ob der Sleep 10ms oder 100ms lang ist. Unschön ist, dass die Temperatur teilweise, Humidity aber immer mehrfach geloggt wird.

Ich hoffe, dass es dafür noch eine "saubere" Lösung gibt.

Mx112

Mir ist jetzt auch aufgefallen das ich ein device habe wo das reading was ich per notify abfage nicht ins log geschrieben wurde. Hab jetzt den sleep mit eingebaut und nun erscheints.

interesannt ist das das auch ein Problem mit dem log von userReadings behebt:

Log ohne sleep:
2014-02-16_09:46:39 KG.k1.EM.Sicherungskasten wakeup: notification
2014-02-16_09:46:39 KG.k1.EM.Sicherungskasten energy: 3397.027
2014-02-16_09:46:39 KG.k1.EM.Sicherungskasten lastEnergy: 0


Log mit sleep:
2014-02-16_13:46:52 KG.k1.EM.Sicherungskasten wakeup: notification
2014-02-16_13:46:52 KG.k1.EM.Sicherungskasten energy: 3398.96
2014-02-16_13:46:52 KG.k1.EM.Sicherungskasten config_09: 254931
2014-02-16_13:46:52 KG.k1.EM.Sicherungskasten energy: 3399.08
2014-02-16_13:46:52 KG.k1.EM.Sicherungskasten lastEnergy: 120


config_09 ist das reading, energy und lastEnergy userReadings.
energy { int ( 1000 * ( ReadingsVal($name,"config_09",0) / 75 ) +0.5 ) / 1000 }, lastEnergy difference { ReadingsVal($name,"energy",0) * 1000 }
FHEM 5.5 SVN - FB7390 FRITZ!OS 06.03 - RaspberryPi - Z-Wave - FBDECT

Manylion

Hallo zusammen.
Ich führe den Fred mal fort mit meinen Erfahrungen zum ST814.
Gerät wurde nach dem Pairen mit Autocreate angelegt.
Dabei wurden gleich drei Geräte angelegt:
ZWave_SENSOR_MULTILEVEL_4
ZWave_SENSOR_MULTILEVEL_4.01
ZWave_SENSOR_MULTILEVEL_4.02
Die Eigenschaften der Geräte stehen weiter unten.

Als batteriebetriebenes Gerät arbeitet es mit wakeup notifications, diese habe ich mit
set ZWave_SENSOR_MULTILEVEL_4 wakeupIntervall 300 1
auf 5 Minuten gesetzt.
Die Readings bekomme ich mit einem AT:
define get_temp_hum at +*00:05:00 get ZWave_SENSOR_MULTILEVEL_4.01 smStatus;;get ZWave_SENSOR_MULTILEVEL_4.02 smStatus
Dieses AT schreibt die Anforderungen in eine Warteschlange, die bei jeder wakeup notification automatisch an das Gerät geschickt wird.
Das Gerät sendet dann die readings zurück.

Soweit funktioniert das alles.
Ein Schönheitsfehler ist, dass das Internal "state" immer mit ? ? ? belegt ist.

Ich hoffe, dass der Eine oder Andere diese Infos hilfreich findet, oder zu neuen Diskussionen anregt.

RasPi, CUL868, HM Rolläden und Lichtschalter, Z-Wave, FB7490, FRITZ!DECT Steckdosen und Heizung, AVR Pioneer1183 mit Onkyo-Modul, Tradfri, Sonoff, 360°IR WLAN GW, HM-WLAN-GW

krikan

Zitat von: Manylion am 05 Dezember 2017, 11:00:42
Ein Schönheitsfehler ist, dass das Internal "state" immer mit ? ? ? belegt ist.
Kann man mit dem Attribut stateFormat aendern (https://fhem.de/commandref.html#stateFormat).

Gruß, Christian

Manylion

#39
Hallo Christian,

danke für den Hinweis mit dem stateformat. Klappt :-)
Bin zwar schon weit gekommen mit Fhem, sodass vieles funktioniert, aber es war noch keine Zeit, das Ganze aufzuhübschen und mich mit den ganzen attribute und set Möglichkeiten zu befassen.
Kommt schon noch alles, mit der Zeit.

Update zum ST814:
Warum auch immer, die readings sind mehr geworden (ich hab nix gemacht ;-) ), siehe screenshot.
Hab inzwischen herausgefunden, dass die wakuptime in Sekunden, die AutoReportTime aber in Minuten angegeben wird.

Hab nun
set ZWave_SENSOR_MULTILEVEL_4 configAutoReportHumidity 1
set ZWave_SENSOR_MULTILEVEL_4 configAutoReportTemperature 1
set ZWave_SENSOR_MULTILEVEL_4 configAutoReportTime 10

gesetzt und mein get_temp_hum AT gelöscht.
Die Kinder
ZWave_SENSOR_MULTILEVEL_4.01
ZWave_SENSOR_MULTILEVEL_4.02
brauch ich jetzt nicht mehr und habe sie in den Raum hidden geschoben.
RasPi, CUL868, HM Rolläden und Lichtschalter, Z-Wave, FB7490, FRITZ!DECT Steckdosen und Heizung, AVR Pioneer1183 mit Onkyo-Modul, Tradfri, Sonoff, 360°IR WLAN GW, HM-WLAN-GW