[reloaded] TvHeadend-Modul

Begonnen von Beta-User, 25 September 2021, 20:48:56

Vorheriges Thema - Nächstes Thema

Beta-User

Hallo zusammen,

unter Codeschnipsel hatte @Quantum mal einen ersten Entwurf für ein Tvheadend-Modul veröffentlicht, das dann aber anscheinend nicht mehr weiterverfolgt. Bin irgendwie neulich mal da drüber gestolpert, und dachte, TvHeadend - das habe ich doch auch, mal sehen, was man damit anstellen kann....?

Hier mal seine Ankündigung - das paßt erst mal auf "meine" Version:
Zitat von: Quantum am 18 März 2018, 22:38:01
Hallo FHEM-Gemeinde,

schon seit Jahren verwendet ich als TV den Tvheadend Server in Verbindung mit Kodi -> https://github.com/tvheadend/tvheadend
Tvheadend bietet eine wenig bekannte und eher mager dokumentierte JSON Schnittstelle, über die so ziemlich alles manipuliert werden kann.
Das habe ich zum Anlass genommen hierfür ein Modul zu schreiben, das ich nun als ersten Wurf veröffentliche.

Siehe hierzu: [alter link] und die commandref.

Was kann das Modul zu diesem Zeitpunkt ?

Intelligente Abfrage des EPGs. Was läuft gerade und als nächstes im TV?. Hierfür werden verschiedene readings angelegt. Titel,Beschreibung,Sendername,Start,Stop ...
Erneute Abfrage des EPG bei Ende einer Sendung.

Abfragen des EPGs mithilfe einer get Methode.

Anlegen eines DVR(Digital Video Recorder) Eintrags mithilfe einer EventId.

Mögliches Anwendungszenario: Abfrage von EPG Informationen aus der Ferne mithilfe eines Endgeräts bspw. Smartphone (Messenger), Email etc..
Daraufhin setzen enes DVR Eintrags mithilfe dieser Information aus der Ferne. Ohne zuhause zu sein, bzw. Kodi starten zu müssen.

Frühe Entwicklerversion. Fehlverhalten nicht ausgeschlossen !

Freundliche Grüße
Quantum

Es gab ein paar (m.E. teils sehr berechtigte) Anmerkungen von CoolTux zum Coding, daher habe ich das jetzt erst mal in der Funktionalität mehr oder weniger nur 1:1 versucht, auf "json_de/encode"-sichere Mechanismen und auf package umzustellen.

Weitere Änderungen:
- das UTF-8-encoding schien gelegentlich "kaputt" zu sein - teilweise ist es repariert
- User/Passwort kann zwar noch über die DEF eingegeben werden, gespeichert wird dann aber in Attribut bzw. im "Passwortspeicher", dazu gäbe es dann auch neue Setter
- Der Modulname ist jetzt TvHeadend (mit großem "H"). So kann man auch beide Fassungen parallel verwenden;
- intern ist auch sonst einiges umgestellt.

Diese Version hier kann also (hoffentlich) in Ergebnis noch dasselbe wie die letzte Fassung von Quantum, intensiv getestet habe ich aber auch noch nicht ::) , und eine "größere Idee", warum man sowas überhaupt braucht, ebenfalls nicht...

Bin daher mal auf mutige Tester gespannt - mal schauen, was am Ende daraus wird.

Vieles am Code ist mir auch noch unklar und kann ggf. noch verbessert werden.

Viel Spaß beim Testen,

Beta-User

EDIT: Update vom 11.10.2021 - die gesamt-Channel-Liste wird nicht mehr als userAttr bereitgestellt, sondern per Instanz.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

alanblack

Hi, ich habe es mal runtergeladen,

Zitat von: Beta-User am 25 September 2021, 20:48:56
Hier mal seine Ankündigung - das paßt erst mal auf "meine" Version:

Auf jeden Fall mal: Danke für die Arbeit!
aber da passt noch nicht alles:
Internals:
   CFGFN     
   DEF        baseUrl=<IP>
   EPGQuery_state 0
   FUUID      <ID>
   NAME       TVHeadendServer
   NR         52646
   STATE      ???
   TYPE       TvHeadend
   READINGS:
   helper:
     epg:
       count      43
       update     1633630260
       channels:
         HASH(0x660acc8)
         HASH(0x61bc4b8)
         HASH(0x5af7478)
         HASH(0x6588b28)
         HASH(0x646feb0)
         HASH(0x660a9f8)
         HASH(0x6410280)
         HASH(0x62ccc88)
         HASH(0x6022e78)
         HASH(0x669b4c8)
         HASH(0x61b1c78)
         HASH(0x57f2318)
         HASH(0x66a1c28)
         HASH(0x66db5e0)
         HASH(0x5da5a58)
         HASH(0x643a290)
         HASH(0x647dfd8)
         HASH(0x5ae6d10)
         HASH(0x66da200)
         HASH(0x5db8530)
         HASH(0x58809d8)
         HASH(0x642f2e0)
         HASH(0x62339f8)
         HASH(0x5ea4668)
         HASH(0x633d728)
         HASH(0x5e3f620)
         HASH(0x60eb6f8)
         HASH(0x5a6b898)
         HASH(0x635caa8)
         HASH(0x6471058)
         HASH(0x61b2898)
         HASH(0x647d9d8)
         HASH(0x5cd8310)
         HASH(0x5ed1600)
         HASH(0x57dbd30)
         HASH(0x62ef3a0)
         HASH(0x5d9d7f0)
         HASH(0x66ea040)
         HASH(0x65cfb40)
         HASH(0x6380410)
         HASH(0x64aedf8)
         HASH(0x65f7a38)
         HASH(0x5f12b90)
         HASH(0x66d5e48)
         HASH(0x5d8ef28)
         HASH(0x60d2be8)
         HASH(0x58056a0)
         HASH(0x5a66100)
         HASH(0x5f125f0)
         HASH(0x667f990)
       next:
         HASH(0x5dc8718)
         HASH(0x641f628)
         HASH(0x66919b8)
         HASH(0x6233788)
         HASH(0x652e148)
         HASH(0x66c6308)
         HASH(0x431b948)
         HASH(0x5a46940)
         HASH(0x64eb3f0)
         HASH(0x6329500)
         HASH(0x5fc29f8)
         HASH(0x3d179c0)
         HASH(0x595a688)
         HASH(0x637fac8)
         HASH(0x61da740)
         HASH(0x64388d8)
         HASH(0x64c2fe0)
         HASH(0x630cb48)
         HASH(0x6306dd8)
         HASH(0x6370118)
         HASH(0x5aefc98)
         HASH(0x57d7120)
         HASH(0x6588138)
         HASH(0x5ae7f98)
         HASH(0x66d2770)
         HASH(0x57ce170)
         HASH(0x5de03f8)
         HASH(0x6403848)
         HASH(0x64ea140)
         HASH(0x5d19100)
         HASH(0x6517f68)
         HASH(0x6563e28)
         HASH(0x62e20f0)
         HASH(0x668f120)
         HASH(0x6112d78)
         HASH(0x66cb4d0)
         HASH(0x61f3920)
         HASH(0x58b8348)
         HASH(0x5da5d40)
         HASH(0x58ceaa8)
         HASH(0x6381e60)
         HASH(0x6568c08)
         HASH(0x67200a0)
       now:
         HASH(0x5a75cf0)
         HASH(0x60ebdd0)
         HASH(0x6381208)
         HASH(0x6022ab8)
         HASH(0x64adb88)
         HASH(0x6347210)
         HASH(0x63a4220)
         HASH(0x66a9790)
         HASH(0x5814b70)
         HASH(0x5d9cf38)
         HASH(0x63a1fe8)
         HASH(0x665b990)
         HASH(0x57d4a88)
         HASH(0x5ed3ec8)
         HASH(0x6415af0)
         HASH(0x5db29c8)
         HASH(0x5c4f900)
         HASH(0x66800f8)
         HASH(0x665d558)
         HASH(0x5d9ed48)
         HASH(0x67af710)
         HASH(0x632b408)
         HASH(0x6391958)
         HASH(0x5dab630)
         HASH(0x65c2078)
         HASH(0x5f876f8)
         HASH(0x6347ac8)
         HASH(0x6505168)
         HASH(0x64764f0)
         HASH(0x6029548)
         HASH(0x5ea04f8)
         HASH(0x61e3118)
         HASH(0x64f97f0)
         HASH(0x5d9ece8)
         HASH(0x6680158)
         HASH(0x662b460)
         HASH(0x6475b60)
         HASH(0x6692c20)
         HASH(0x612c518)
         HASH(0x60c2388)
         HASH(0x6678b80)
         HASH(0x62cd210)
         HASH(0x64150a8)
     http:
       id         11
       ip         <IP>
       port       9981
       url        <url>
Attributes:
   Username   <user>
   userattr   EPGChannelList:multiple-strict,all,R[...]


Die Attribute werden nicht korrekt aufgebaut. Ich habe zwar kurz in den Code geschaut, aber noch nicht den Grund gesehen.

Zitat
[...], und eine "größere Idee", warum man sowas überhaupt braucht, ebenfalls nicht...
Warum ich diesen Thread gefunden habe: ich habe mehrere DVB-Adapter an einem 1-Platinen-Computer hängen, von denen sich beliebige völlig unerwartet und scheinbar zufällig weghängen. Einen Grund habe ich auf OS- und Treiber-Ebene noch nicht gefunden, auch weil es schwierig ist, den Zeitpunkt halbwegs genau einzugrenzen. Daher war der Gedanke, dass ich über die JSON-Schnittstelle das mal genauer mitbekomme.

Zitat
Bin daher mal auf mutige Tester gespannt - mal schauen, was am Ende daraus wird.

"Hier!" (Tester++)

Grüße
FHEM 6.0 auf raspi3&ODROID XU4 mit HMLAN und HM-MOD-RPI-PCB, LaCrosse via JeeLink, COC868 und CUL433, Xiaomi Aqara+div. Zigbee via deCONZ, Dooya via SIGNALDuino, ZWave mit Danalock
Jeder Witz kann ein Einzeiler sein mit genügend Semikolons

MadMax-FHEM

Ich häng mich auch hier mal mit dran :)

Aktuell aber unterwegs, daher wird erst später getestet...

@alanblack: was für ein 1-Platinencomputer? USB zu "schwach"? Habe ich bei einem meiner PI auch. 2x USB-Adapter und USB-SSD und ab und an "verschwindet" einer... Hab da jetzt (aktuell) nur einen laufen...

An einem weiteren PI einen Dual-Stick und ebenfalls USB-SSD aber mit aktivem USB-Hub (zuvor ohne auch mit Problemen) keine Probleme...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

alanblack

Hallo Joachim,

[Offtopic]
Zitat von: MadMax-FHEM am 07 Oktober 2021, 20:34:50
@alanblack: was für ein 1-Platinencomputer? USB zu "schwach"? Habe ich bei einem meiner PI auch. 2x USB-Adapter und USB-SSD und ab und an "verschwindet" einer... Hab da jetzt (aktuell) nur einen laufen...
Der Computer ist ein Odroid XU4. Daran hängen bis auf eine USB-HDD an zwei passiven USB-Hubs jeweils zwei USB-DVB-Adapter - aktuell jeder mit eigenem Netzteil. Das war mal aus Verbrauchsgründen anders, aber wegen der Probleme hatte ich schon alles mir erdenkliche getan, um derartige Ursachen auszuschließen.
Die Kombi so läuft auch mit bis zu vier Streams bei zwei mit Transcoding ohne Mucken. Nur mehr als ein SD- und ein HD-Stream im Timeshift bringen die HDD an die Grenzen - da müsste dann eine SSD hin.
Ein Problem unter Last habe ich nicht verzeichnen können - eher im Idle. Da ich dann aber i.d.R. nicht zuhause bin, bekomme ich aktuell den Ausfall nur mit, wenn ich über fehlgeschlagene Aufnahmen stolpere oder die Meldung "Kein freier Adapter verfügbar" mich anspringt.
[/Offtopic]

Die Stromversorgung wird aber sehr sicher nicht für das nicht korrekte Initialisieren der Attribute dieses Moduls verantwortlich sein.

Grüße
FHEM 6.0 auf raspi3&ODROID XU4 mit HMLAN und HM-MOD-RPI-PCB, LaCrosse via JeeLink, COC868 und CUL433, Xiaomi Aqara+div. Zigbee via deCONZ, Dooya via SIGNALDuino, ZWave mit Danalock
Jeder Witz kann ein Einzeiler sein mit genügend Semikolons

Beta-User

Leider fehlt mir noch eine Idee, was genau mit "Attribute werden nicht korrekt aufgebaut" gemeint ist - vermutlich fehlt mir der "vorher/nachher"-Aha-Effekt.

Das userattr EPGChannelList wird doch aufgebaut, oder deute ich das [...] falsch? Was  fehlt?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

alanblack

Zitat von: Beta-User am 07 Oktober 2021, 22:26:32
Leider fehlt mir noch eine Idee, was genau mit "Attribute werden nicht korrekt aufgebaut" gemeint ist - vermutlich fehlt mir der "vorher/nachher"-Aha-Effekt.
[IronieAn]Das sieht man doch aus dem List.[IronieAus] :P

Zitat
Das userattr EPGChannelList wird doch aufgebaut, oder deute ich das [...] falsch? Was  fehlt?
Reicht nicht immer - also Screenshot anbei!
Die kommaseparierte Liste scheint an der falschen Stelle zu landen. Oder wenn das über das Attribut "userattr" gewollt ist, wäre das Leerzeichen statt Kommata als Trennzeichen erforderlich.

Grüße
FHEM 6.0 auf raspi3&ODROID XU4 mit HMLAN und HM-MOD-RPI-PCB, LaCrosse via JeeLink, COC868 und CUL433, Xiaomi Aqara+div. Zigbee via deCONZ, Dooya via SIGNALDuino, ZWave mit Danalock
Jeder Witz kann ein Einzeiler sein mit genügend Semikolons

Beta-User

Ironiefrei: Der Inhalt von userAttr sah für mich ok aus. Nach meinem bisherigen Verständnis ist es so, dass man erst das userAttr generieren muss, um dann in einem zweiten Schritt dann die EPGChannelList auswählen zu können.

Das Problem ist eher, dass die letztere dann verlustigt geht, wenn man danach dann set ... EPG ausführt. Da ich aber nicht weiß, wie das im Ausgangsmodul war, und wie das eigentlich alles gedacht war, ist es schwierig zu beurteilen, ob das nun eine Regression ist oder nicht. Aber dass ein set-Befehl ein Attribut löscht, ist eher nicht so intuitiv, sieht mir nach einem Bug aus, mal sehen....
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

alanblack

#7
Nachtrag: ich hatte einmal das Device angelegt, mich gewundert und ein "get ChannelQuery" gemacht. Danach habe ich es gelöscht und noch einmal angelegt. Da war das userattr wie im Screenshot vorhanden.
Jetzt habe ich das Device mal unter einem anderen Namen angelegt:
Internals:
   CFGFN     
   DEF        baseUrl=<IP>
   FUUID      6162af46-f33f-c82a-5839-f5f1b47ef913240e
   NAME       TVHeadendServer_1
   NR         91069
   STATE      ???
   TYPE       TvHeadend
   helper:
     epg:
       count      0
     http:
       ip         <IP>
       port       9981
       url        <URL>
Attributes:

Jetzt weiß ich wieder, warum ich mich gewundert habe: das Device ist "leer".
Darf aber laut Code nicht sein, oder?

$hash->{AttrList} =
"HTTPTimeout " .
"EPGVisibleItems:multiple-strict,Title,Subtitle,Summary,Description,ChannelName,ChannelNumber,StartTime,StopTime " .
"PollingQueries:multiple-strict,ConnectionQuery " .
"PollingIntervall " .
"EPGChannelList:multiple-strict,all " .
          $readingFnAttributes;


Grüße
FHEM 6.0 auf raspi3&ODROID XU4 mit HMLAN und HM-MOD-RPI-PCB, LaCrosse via JeeLink, COC868 und CUL433, Xiaomi Aqara+div. Zigbee via deCONZ, Dooya via SIGNALDuino, ZWave mit Danalock
Jeder Witz kann ein Einzeiler sein mit genügend Semikolons

Beta-User

So, update ist im ersten Post. Damit wird EPGChannelList nicht mehr als userattr generiert, sondern entweder als echtes Attribut gelesen oder instanzspezifisch verwaltet.

Heißt aber noch lange nicht, dass das irgendwas bringen würde - im alten Thread war die Rede davon, dass das "unvollendet" sei... So auch hier :o ;D ...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

alanblack

Zitat von: Beta-User am 11 Oktober 2021, 21:41:11
So, update ist im ersten Post. Damit wird EPGChannelList nicht mehr als userattr generiert, sondern entweder als echtes Attribut gelesen oder instanzspezifisch verwaltet.
Runtergeladen, "alte" Version komplett bereinigt, neue rein => funktioniert jetzt anscheinend stabil
Vielen Dank dafür!

Zitat
Heißt aber noch lange nicht, dass das irgendwas bringen würde - im alten Thread war die Rede davon, dass das "unvollendet" sei... So auch hier :o ;D ...
Ich habe inzwischen die API für die Input-Devices vom TVHeadend-Server gefunden. Ich schaue mal, was ich davon umsetzen kann.

Grüße
FHEM 6.0 auf raspi3&ODROID XU4 mit HMLAN und HM-MOD-RPI-PCB, LaCrosse via JeeLink, COC868 und CUL433, Xiaomi Aqara+div. Zigbee via deCONZ, Dooya via SIGNALDuino, ZWave mit Danalock
Jeder Witz kann ein Einzeiler sein mit genügend Semikolons

Beta-User

...einen habe ich noch gefunden: Die Attribute in .AttrList scheinen sich zu vervielfachen...

Fix (hoffentlich) - Zeile 511 so ändern:
my $devattrs = $defs{$name}{'.AttrList'} // getAllAttr($name);
Zitat von: alanblack am 13 Oktober 2021, 22:05:02
Ich habe inzwischen die API für die Input-Devices vom TVHeadend-Server gefunden. Ich schaue mal, was ich davon umsetzen kann.
Bitte gib Bescheid, wenn du Hilfe brauchst.

Vielleicht noch was für den Hinterkopf: Wenn man einen nicht administrativen Nutzer hat, gibt es auch entsprechende Rückmeldungen, wenn man was versucht, was nicht erlaubt ist (war eine der Absturzursachen aus dem anderen Thread, weil dann kein JSON zurückkommt). Vielleicht muss/sollte man das irgendwo sichtbar machen, dass bzw. mit welchem Ergebnis das gecheckt wurde.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

alanblack

Zitat von: Beta-User am 13 Oktober 2021, 22:37:41
...einen habe ich noch gefunden: Die Attribute in .AttrList scheinen sich zu vervielfachen...

Fix (hoffentlich) - Zeile 511 so ändern:
my $devattrs = $defs{$name}{'.AttrList'} // getAllAttr($name);
Bisher habe ich auch ohne diesen Fix keine Vervielfachung erkennen können. Ich habe ein Auge darauf.
Zitat[Input-Devices]
Bitte gib Bescheid, wenn du Hilfe brauchst.
OK! Danke für das Angebot! Werde aber frühestens nächste Woche Zeit finden.
Zitat
Vielleicht noch was für den Hinterkopf: Wenn man einen nicht administrativen Nutzer hat, gibt es auch entsprechende Rückmeldungen, wenn man was versucht, was nicht erlaubt ist (war eine der Absturzursachen aus dem anderen Thread, weil dann kein JSON zurückkommt). Vielleicht muss/sollte man das irgendwo sichtbar machen, dass bzw. mit welchem Ergebnis das gecheckt wurde.
Wäre vielleicht etwas, das den STATE beeinflussen könnte, so in der Art: Server liefert reguläre Antworten => STATE = "connected" (oder so) - irgendein Input geht nicht => STATE = "warning" - User macht Unsinn => STATE = "alert". Auch nur für den Hinterkopf; eigentlich aber, weil mich die "? ? ?" im STATE irritieren. 

Grüße
FHEM 6.0 auf raspi3&ODROID XU4 mit HMLAN und HM-MOD-RPI-PCB, LaCrosse via JeeLink, COC868 und CUL433, Xiaomi Aqara+div. Zigbee via deCONZ, Dooya via SIGNALDuino, ZWave mit Danalock
Jeder Witz kann ein Einzeiler sein mit genügend Semikolons

Beta-User

Das mit "sehr vielen comment-Einträgen" ist bei mir halt vorgekommen, warum auch immer. Jetzt mit dem fix erst mal auch nicht mehr ;D .

Was STATE angeht => stateFormat würde helfen. Mit dem "verfrühten" Füllen des Readings "state" habe ich so meine Erfahrungen gemacht, seither reserviere ich das für den "Hauptschalter" ;D ...

Aber sowas wie ein "connection"-Reading würde Sinn machen, etwa in die Richtung: unreachable, unauthorized, ok, priviledged. Tendenziell würde man sowieso sowas wie eine "ping"-Routine brauchen (Rudi hat da was im Repertoire, man braucht kein qx...).

Das Logging von den nächsten Verbindungsversuchs-Zeiten auf Level 3 erscheint mir auch nicht optimal, sollte eigentlich auch eher ein Reading sein.

(Vielleicht bei Gelegenheit mal).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

alanblack

#13
Zitat von: Beta-User am 13 Oktober 2021, 22:37:41
[InputDevices]
Bitte gib Bescheid, wenn du Hilfe brauchst.
Die Abfrage habe ich eingebaut. Ich bin mir nicht klar, ob ich die Devices in Attribute, ein Internal (aktuell) oder Readings ablegen sollte. Die "activeInputDevices" habe ich auf jeden Fall als Reading angelegt. Nur hatte ich irgendetwas mit dem InternalTimer darauf falsch gemacht. Damit war FHEM eingefroren. Das ist hier komplett wieder draußen. Kannst Du mir da mal bitte zumindest einen Ansatz geben. Danke!

Grüße
FHEM 6.0 auf raspi3&ODROID XU4 mit HMLAN und HM-MOD-RPI-PCB, LaCrosse via JeeLink, COC868 und CUL433, Xiaomi Aqara+div. Zigbee via deCONZ, Dooya via SIGNALDuino, ZWave mit Danalock
Jeder Witz kann ein Einzeiler sein mit genügend Semikolons

CoolTux

Zitat von: Beta-User am 14 Oktober 2021, 20:51:58
Das mit "sehr vielen comment-Einträgen" ist bei mir halt vorgekommen, warum auch immer. Jetzt mit dem fix erst mal auch nicht mehr ;D .

Was STATE angeht => stateFormat würde helfen. Mit dem "verfrühten" Füllen des Readings "state" habe ich so meine Erfahrungen gemacht, seither reserviere ich das für den "Hauptschalter" ;D ...

Aber sowas wie ein "connection"-Reading würde Sinn machen, etwa in die Richtung: unreachable, unauthorized, ok, priviledged. Tendenziell würde man sowieso sowas wie eine "ping"-Routine brauchen (Rudi hat da was im Repertoire, man braucht kein qx...).

Das Logging von den nächsten Verbindungsversuchs-Zeiten auf Level 3 erscheint mir auch nicht optimal, sollte eigentlich auch eher ein Reading sein.

(Vielleicht bei Gelegenheit mal).

Vielleicht hilft das etwas beim Thema connection

https://wiki.fhem.de/wiki/DevelopmentGuidelinesAV



Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net