Hauptmenü

Neueste Beiträge

#1
Zigbee / Aw: tradfri-fhem tester gesuch...
Letzter Beitrag von tomcat.x - 23 April 2024, 15:19:12
Mir ist gerade beim Herumspielen und Vergleichen von Tradfri Bewegungsmeldern, die ich entweder per Tradffri Gateway oder DeCONZ angebunden habe, folgendes aufgefallen: Bei allen per tradfri angebundenen bekomme ich Readings und Events für battery, batteryPercent und reachable mit falschen Zeitstempeln. Ich dachte immer, diese Readings werden nur alle paar Stunden oder einmal am Tag aktualisiert. Jetzt stelle ich aber fest, dass die mit jeder Bewegungserkennung kommen, aber mit falscher Zeit. Für einige habe ich Logs. Da sehe ich, dass über den ganzen Tag der Zeitstempel der gleiche ist. Manchmal (selten) ändert sich auch das Datum nicht mit dem Tageswechsel, es gibt einzelne Tage ohne Einträge und beispielsweise bekomme ich heute noch Einträge mit Datum von gestern.

Sehen kann ich das Ganze im Event-Monitor, da kommen zwischen Events mit richtiger Zeit dann die der Bewegungsmelder mit falscher. Oder im Gerät selbst, da werden die Zeitstempel der drei Readings bei einer Bewegungserkennung auf einmal rot, aber Datum und Uhrzeit ändern sich nicht.

Ist das ein Problem in meiner Installation oder ein generelles? Hat jemand eine Idee, woran das dann liegen könnte?

Viele Grüße
Thomas
#2
FHEM Development / Aw: Zugang zu Github Copilot a...
Letzter Beitrag von CoolTux - 23 April 2024, 14:26:52
Kann ich mir gerne heute Abend anschauen wenn Sidney nicht zufällig schneller ist 😃
#3
Homematic / Aw: HM-LC-Ja1PBU-FM Verbindung...
Letzter Beitrag von frank - 23 April 2024, 14:20:49
moin.

1. als erstes würde ich mal die warnings eleminieren, die durch das userreading stateInverted im else block entstehen, wenn strings (zb set_on) im state kommen.
hat aber nichts mit dem problem zu tun.
stateInverted {
    if(   ReadingsVal($NAME,"state","") eq "on")          {return 0}
    elsif(ReadingsVal($NAME,"state","") eq "MISSING ACK") {return "MISSING ACK"}
    elsif(ReadingsVal($NAME,"state","") eq "off")         {return 100}
    elsif(ReadingsVal($NAME,"state","") eq "set_stop")    {return "stop"}
    elsif(ReadingsVal($NAME,"state","") eq "unreachable") {return "unreachable!!"}
    else                                                  {return int((ReadingsVal($NAME,"state",0)-100)*-1)}
}


2. zum log
zunächst werden alle befehle (up, down, stop) vom device beantwortet. auch stop beim hochfahren. 

igendwann kommen (fast) keine antworten mehr vom device (80 02 6686E7 12AEB3 ...).
es begint mit stop beim hochfahren (4x), danach aber auch 1x beim down.
die down wiederholung wird wieder beantwortet, aber folgende 2 stops auch nicht.
2024.04.23 08:24:13.592 0: HMUARTLGW myHmUART send: 01 02 00 00 00 msg: 52 A0 11 12AEB3 6686E7 8001C8CA
2024.04.23 08:24:13.752 0: HMUARTLGW myHmUART recv: 01 04 03 00 39 msg: 52 80 02 6686E7 12AEB3 01011010 44 3C01

2024.04.23 08:24:15.928 0: HMUARTLGW myHmUART send: 01 02 00 00 00 msg: 53 A0 11 12AEB3 6686E7 0301
2024.04.23 08:24:19.128 0: HMUARTLGW myHmUART send: 01 02 00 00 00 msg: 53 A0 11 12AEB3 6686E7 0301
2024.04.23 08:24:23.652 0: HMUARTLGW myHmUART send: 01 02 00 00 00 msg: 53 A0 11 12AEB3 6686E7 0301
2024.04.23 08:24:29.290 0: HMUARTLGW myHmUART send: 01 02 00 00 00 msg: 53 A0 11 12AEB3 6686E7 0301
2024.04.23 08:25:22.828 0: HMUARTLGW myHmUART send: 01 02 00 00 00 msg: 54 A0 11 12AEB3 6686E7 800100CA

2024.04.23 08:25:26.040 0: HMUARTLGW myHmUART send: 01 02 00 00 00 msg: 54 A0 11 12AEB3 6686E7 800100CA
2024.04.23 08:25:26.496 0: HMUARTLGW myHmUART recv: 01 04 03 00 35 msg: 54 80 02 6686E7 12AEB3 01013220 44 C802

2024.04.23 08:25:29.363 0: HMUARTLGW myHmUART send: 01 02 00 00 00 msg: 55 A0 11 12AEB3 6686E7 0301
2024.04.23 08:25:33.362 0: HMUARTLGW myHmUART send: 01 02 00 00 00 msg: 55 A0 11 12AEB3 6686E7 0301

es gibt viele möglichkeiten, warum keine antworten zu sehen sind.
1. hmuart hat die cmd nicht gesendet
2. device hat die cmd nicht gehört
3. device konnte keine antworten senden, wegen 1% regel
4. hmuart hat die antworten nicht gehört

ich vermute aber, dass das device trotzdem gestoppt hat, denn die up fahrt begann bei 8% und die nächste antwort beim down zeigt nur 25%, mehr als 1min später.
ob der aktor wirklich reagiert, kannst nur du beurteilen.

die rssi zeigen auch einen leichten hörschaden.

vielleicht zeigt der aktor aber auch die ersten anzeichen des berühmten sterbens eines bestimmten kondensators?


ich würde mal einen werkreset über den configtaster machen, anschliessend neu anlernen.
fhem device aber nicht löschen.
wenn das nicht hilft, wahrscheinlich den kondensator tauschen.

#4
FHEM Development / Zugang zu Github Copilot als e...
Letzter Beitrag von Volker Kettenbach - 23 April 2024, 13:59:28
Hallo,

ich bin auf Github Mitglied der FHEM-Organisation, aber kein Admin derer.
In meinem Account kann ich sehen, dass Admins der FHEM-Organisation Copilot über diese verwenden können.
Das würde ich gerne.
Geht das irgendwie auch für "normale" Mitglieder oder kann ich Admin werden?

Gruß
Volker
#5
DOIF / HTTP POST bzw. curl in DOIF ei...
Letzter Beitrag von blueberry63 - 23 April 2024, 13:58:58
Hallo,

da ich mir hier schon eine Weile einen "abmurkse", frage ich mal hier nach.

Ich möchte ein Gerät in DOIF über HTTP Post schalten. Den eigentlichen Schaltvorgang habe ich auf der Konsole mittels CURL auch geschafft:

curl --location --request POST 'http://192.168.xxx.xxx:7070/api/loadpoints/3/mode/off (wen es interessiert: es handelt sich hier um einen Heizstab in EVCC)

Könnte mir jemand erklären, wie man das in DOIF einbaut?

SO funktioniert es jedenfalls nicht:

defmod di_heizstab_maxtemp_evcc DOIF ([OekoFEN:WW-Temp-Ein-Ist] > 60 and [Heizstab_Puffersp] eq "on" ) ({ GetHttpFile("192.168.xxx.xxx:7070/", "api/loadpoints/3/mode/off") }) DOELSEIF ([OekoFEN:WW-Temp-Ein-Ist] <=53 ) ({ GetHttpFile("192.168.xxx.xxx:7070/", "api/loadpoints/3/mode/pv") })


Danke und Gruß
Blueberry63
#6
DOIF / Aw: DOIF bleibt bei cmd_1 steh...
Letzter Beitrag von juemuc - 23 April 2024, 13:46:44
Hat das Attribut "do allways" nicht funktioniert? Das spart den "dummy-Zweig".

Viele Grüße
Jürgen
#7
Homematic / Aw: HMCCU 5.0 im SVN verfügbar
Letzter Beitrag von juemuc - 23 April 2024, 13:38:41
Hallo zap,

das hatte ich schon fast vermutet. Da ich nicht der große Programmierer bin, würde ich gerne bei Dir ein bisschen "abschreiben". Kannst Du mir sagen, wie bzw. wo Du die Infos für "get week-program" ermittelst? Dann kann ich zumindest lernen, wie die Zugriffe erfolgen, um die relevanten Daten zu ermitteln.

Danke im Vorraus.

Viele Grüße
Jürgen
#8
Homematic / Aw: HmIP-DLD Keine Statusübert...
Letzter Beitrag von zap - 23 April 2024, 13:30:50
Ich habe immer mehr den Eindruck, dass die RPC Server nicht laufen oder eine Firewall Einstellung verhindert, dass die Daten in FHEM ankommen
#9
Homematic / Aw: HMCCU 5.0 im SVN verfügbar
Letzter Beitrag von zap - 23 April 2024, 13:28:27
Ich würde nicht die Ausgabe von get week-program verwenden sondern die Readings. Da stehen die Schaltzeiten ja drin. Du wirst aber nicht um eine kleine Perl-Funktion rum kommen.
#10
Marktplatz - Güter / Aw: S: Homematic HM-Sec-ScO Tü...
Letzter Beitrag von UliD - 23 April 2024, 13:17:10
@hobu:

Moin,

hab dir vor zwei Wochen ein Angebot gemacht. Eine Antwort wäre nett...