Neue Geräte für CUL_HM anlegen ohne Anlernen

Otto123 · 30 August 2019, 10:01:03

Moin,

ZitatEs macht wenig Sinn, hier die grundsätzliche Entscheidung des Entwicklers, das dem Zugriff des Users zu entziehen, in Zweifel zu ziehen wegen der seltenen Ausnahmefälle, in denen man irgendeinen "Kompabilitätsmodus" braucht, wie z.B. solche Teilumzüge.

Ich will keine Entscheidungen des Entwicklers in Zweifel ziehen. Im Gegenteil, ich möchte ihn gern unterstützen.

Und ich rede auch nicht von seltenen Ausnahmefällen, ich rede über grundlegende Funktionen in FHEM:
define Gerät CUL_HM ... funktioniert quasi nicht mehr!
Realität und Beschreibung stimmen nicht überein! (und ich will auch nicht das die Beschreibung angepasst wird)
Ich möchte mithelfen einen ganz normalen Weg für den User zu gestalten wie er seine Geräte anlegen kann ohne auf geheime Tipps angewiesen zu sein und ohne das Gefühl zu haben etwas "verbotenes" oder "eigentlich falsches" zu tun.

Und ich wollte einen momentanen Weg dokumentieren und wissen ob ich dabei was übersehen habe. Ich selbst habe kein Problem und brauche keine Lösung - aber ich mag es auch nicht, wenn ich selbst Geheimtipps als quasi Standard Hilfe anbieten muss.

Gruß Otto

Beta-User · 30 August 2019, 10:12:05

(Wir sind uns einig, es sollte schon so sein, dass man keine Geheimkenntnisse benötigen sollte, um Geräte händisch zu definieren).

Das define funktioniert, das Problem ist, was danach passiert bzw. danach vom Modul erwartet wird bzw. durchgeführt wird.

Nur als weitere Idee (dieses Mal ggf. auch an Martin): Beim Define einen Marker iVm. einem internaltimer setzen, der den Marker wieder entfernt nach sehr kurzer Zeit (2-5 Sek) , und dann die Prüfung bei $init_done um das alternative Vorhandensein des Markers erweitern. Dann würde typischerweise ein RAW-Input durchlaufen, nicht aber die manuelle Eingabe via Kommandozeile...

Kusselin · 28 Juni 2020, 19:50:35

Hallo Otto,

muss deinen Thread hier nochmal aufmachen..... ich habe einen HMuart den ich mal zum Testen abgemacht habe vom Raspi und auf den Test Raspi gestetzt habe.....VCCU und HMuart opned!!!

Wenn ich jetzt dieses Device von meinem hauptfhem nehme:

Code Auswählen

defmod Garage_Aktor CUL_HM 471C02
attr Garage_Aktor .mId 0061
attr Garage_Aktor IODev myHmUART
attr Garage_Aktor IOgrp VCCU:myHmUART
attr Garage_Aktor alias Garage_Aktor
attr Garage_Aktor autoReadReg 4_reqStatus
attr Garage_Aktor expert 2_raw
attr Garage_Aktor firmware 2.8
attr Garage_Aktor model HM-LC-SW4-DR
attr Garage_Aktor room CUL_HM
attr Garage_Aktor serialNr NEQ0194570
attr Garage_Aktor subType switch
attr Garage_Aktor webCmd getConfig:clear msgEvents

setstate Garage_Aktor CMDs_done
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-lgCtDlyOff geLo
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-lgCtDlyOn geLo
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-lgCtOff geLo
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-lgCtOn geLo
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-lgCtValHi 100
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-lgCtValLo 50
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-lgMultiExec on
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-lgOffDly 0 s
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-lgOffTime unused
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-lgOffTimeMode absolut
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-lgOnDly 0 s
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-lgOnTime unused
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-lgOnTimeMode absolut
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-lgSwJtDlyOff off
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-lgSwJtDlyOn off
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-lgSwJtOff off
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-lgSwJtOn dlyOff
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-shCtDlyOff geLo
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-shCtDlyOn geLo
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-shCtOff geLo
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-shCtOn geLo
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-shCtValHi 100
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-shCtValLo 50
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-shMultiExec off
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-shOffDly 0 s
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-shOffTime unused
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-shOffTimeMode absolut
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-shOnDly 0 s
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-shOnTime unused
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-shOnTimeMode absolut
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-shSwJtDlyOff off
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-shSwJtDlyOn off
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-shSwJtOff off
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-shSwJtOn dlyOff
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-lgCtDlyOff geLo
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-lgCtDlyOn geLo
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-lgCtOff geLo
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-lgCtOn geLo
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-lgCtValHi 100
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-lgCtValLo 50
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-lgMultiExec on
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-lgOffDly 0 s
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-lgOffTime unused
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-lgOffTimeMode absolut
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-lgOnDly 0 s
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-lgOnTime unused
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-lgOnTimeMode absolut
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-lgSwJtDlyOff on
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-lgSwJtDlyOn on
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-lgSwJtOff dlyOn
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-lgSwJtOn on
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-shCtDlyOff geLo
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-shCtDlyOn geLo
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-shCtOff geLo
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-shCtOn geLo
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-shCtValHi 100
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-shCtValLo 50
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-shMultiExec off
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-shOffDly 0 s
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-shOffTime unused
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-shOffTimeMode absolut
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-shOnDly 0 s
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-shOnTime unused
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-shOnTimeMode absolut
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-shSwJtDlyOff on
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-shSwJtDlyOn on
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-shSwJtOff dlyOn
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-shSwJtOn on
setstate Garage_Aktor 2019-01-13 10:29:31 .R-confBtnTime permanent
setstate Garage_Aktor 2019-01-13 10:29:31 .R-intKeyVisib invisib
setstate Garage_Aktor 2019-01-13 10:29:31 .R-localResDis off
setstate Garage_Aktor 2019-01-13 10:29:32 .R-statusInfoMinDly 2 s
setstate Garage_Aktor 2019-01-13 10:29:32 .R-statusInfoRandom 1 s
setstate Garage_Aktor 2019-01-13 10:29:32 .R-transmitTryMax 6
setstate Garage_Aktor 2019-01-13 10:29:33 .peerListRDate 2019-01-13 10:29:33
setstate Garage_Aktor 2020-06-28 08:28:47 .protLastRcv 2020-06-28 08:28:47
setstate Garage_Aktor 2019-01-13 10:29:26 D-firmware 2.8
setstate Garage_Aktor 2019-01-13 10:29:26 D-serialNr NEQ0194570
setstate Garage_Aktor 2020-06-28 08:28:29 PairedTo 0x123123
setstate Garage_Aktor 2019-01-13 10:29:34 R-HM_39CD09_Btn_01-lgActionType jmpToTarget
setstate Garage_Aktor 2019-01-13 10:29:34 R-HM_39CD09_Btn_01-shActionType jmpToTarget
setstate Garage_Aktor 2019-01-13 10:29:35 R-HM_39CD09_Btn_02-lgActionType jmpToTarget
setstate Garage_Aktor 2019-01-13 10:29:35 R-HM_39CD09_Btn_02-shActionType jmpToTarget
setstate Garage_Aktor 2019-01-13 10:29:31 R-pairCentral 0x123123
setstate Garage_Aktor 2019-01-13 10:29:32 R-powerUpAction off
setstate Garage_Aktor 2019-01-13 10:29:32 R-sign off
setstate Garage_Aktor 2020-06-28 08:28:29 RegL_00. 00:00 02:01 0A:12 0B:31 0C:23 15:FF 18:00
setstate Garage_Aktor 2020-06-28 08:28:47 commState CMDs_done
setstate Garage_Aktor 2019-01-13 10:43:47 deviceMsg off (to VCCU)
setstate Garage_Aktor 2019-01-13 10:43:47 level 0
setstate Garage_Aktor 2019-01-13 10:43:47 pct 0
setstate Garage_Aktor 2019-01-13 10:43:47 recentStateType info
setstate Garage_Aktor 2020-06-28 08:28:47 state CMDs_done
setstate Garage_Aktor 2019-01-13 10:43:47 timedOn off

Also das ist die RAW Definition...aber die geht ja so nicht mehr laut deinem Test.....wie kann ich den Aktor nun ohne wieder anlernen im test fhem anlernen???

Ich bekomme auch immer die Meldung:

Code Auswählen

.mId must not be changed by User.
Use modelForce instead

wenn ich jetzt nur zb.

Code Auswählen

define Garage_Aktor CUL_HM 123123 gehts nicht.....dann kommt die Meldung ID ist schon von der VCCU vergeben....

Über ne jurze Hilfe vielen Dank.

Otto123 · 28 Juni 2020, 19:55:58

Wie kommst Du jetzt auf die andere hmId ?
Sollte alles so gehen:

Code Auswählen

defmod Garage_Aktor CUL_HM 471C02
attr Garage_Aktor IODev myHmUART
attr Garage_Aktor IOgrp VCCU:myHmUART
attr Garage_Aktor alias Garage_Aktor
attr Garage_Aktor autoReadReg 4_reqStatus
attr Garage_Aktor expert 2_raw
attr Garage_Aktor firmware 2.8
attr Garage_Aktor modelForce HM-LC-SW4-DR
attr Garage_Aktor room CUL_HM
attr Garage_Aktor serialNr NEQ0194570

attr Garage_Aktor webCmd getConfig:clear msgEvents

Edit: das muss noch raus

Code Auswählen

attr Garage_Aktor subType switch

Sollte sogar nur so gehen, nach meinem ersten Post:

Code Auswählen

define Garage_Aktor CUL_HM 471C02
attr Garage_Aktor modelForce HM-LC-SW4-DR
attr Garage_Aktor IODev myHmUART
attr Garage_Aktor IOgrp VCCU:myHmUART
attr Garage_Aktor firmware 2.8
attr Garage_Aktor room CUL_HM
attr Garage_Aktor serialNr NEQ0194570

Kusselin · 28 Juni 2020, 20:13:19

Hi Otto,
danke...

ich dachte ich muss immer die HMID von der VCCU verwenden.......

Ich probiers morgen mal aus und schreibs dir dann...Danke

Pfriemler · 29 Juni 2020, 10:47:00

Zitat von: Kusselin am 28 Juni 2020, 20:13:19
ich dachte ich muss immer die HMID von der VCCU verwenden.......

Dann fehlt FHEM doch die Info, welche ID das Gerät hat.

Die IO-Geräte (also in diesem Fall das HMUART) sollte die Zentralen-ID (vccu) haben. (Ein zweites IO-Gerät außerhalb der VCCU wiederum sollte eine abweichende HMID haben).

Es geht hier zwar ums "Eintragen ohne Anlernen", aber ich würde aus dem zweiten FHEM doch mal ein "hmPairSerial" mit Seriennummer des Sw4 riskieren. Dann sind define und model schon mal korrekt gesetzt.

Und: wie ich es verstanden habe, willst Du auf dem zweiten System die gleiche Zentralen-ID wie auf dem ersten verwenden? (denn sonst geht es ja gar nicht ohne Anlernen). Allerdings dürfen dann 1. und 2. FHEM nie gleichzeitig in Betrieb sein. Zwei Zentralen mit der gleichen ID zur gleichen Zeit gibt nur jede Menge Kleinholz.

Kusselin · 29 Juni 2020, 11:08:02

Danke Pfriemler...gut erklärt!

Kusselin · 29 Juni 2020, 18:01:57

Zitat von: Kusselin am 28 Juni 2020, 20:13:19
Hi Otto,
danke...

ich dachte ich muss immer die HMID von der VCCU verwenden.......

Ich probiers morgen mal aus und schreibs dir dann...Danke

Hi Otto,
habe den Code so kopiert.....kam aber wieder die Meldung

Code Auswählen

.mId must not be changed by User.
Use modelForce instead

Otto123 · 29 Juni 2020, 21:55:20

Glaub ich Dir nicht.

Bei mir läuft das einwandfrei durch:

Code Auswählen

define Garage_Aktor CUL_HM 471C02
attr Garage_Aktor modelForce HM-LC-SW4-DR
attr Garage_Aktor IODev myHmUART
attr Garage_Aktor IOgrp VCCU:myHmUART
attr Garage_Aktor firmware 2.8
attr Garage_Aktor room CUL_HM
attr Garage_Aktor serialNr NEQ0194570

Bei der ersteren Variante muss die subType Zeile raus, habe es oben geändert. Die Fehlermeldung ist aber eine Andere!

Kusselin · 29 Juni 2020, 22:30:16

Ok schaue und meld mich

martinp876 · 04 Juli 2020, 15:45:56

1) die restriktion der Attribute werden ich beibehalten - ich sehe keinen Grund zum Ändern und keine Anwendugn welche der User nicht machen kann.
2) der Use-Case "Anlegen ohne Anlernen" ist mir nicht klar. Ohne Anlernen geht nichts. Es kann sich also nur um ein Scenario handeln, in welchen der User ein Device gelöscht hat und es nun wieder will. Das KANN er nur in die alte Config gehen und die Attribute kopieren...
2a) dann könnte er es auch in das neue Config hineinkopieren?
2b) er könnte einfach einmal config drücken?
3) modelForce ist die Methode, das model ohne config-message(Anlerntaste! - nicht anlernen) und ohne cfg-file edit - zu setzen. Dann ist alles verfügbar. Warum sollte ich das drehen?

Otto123 · 04 Juli 2020, 17:27:57

2a) geht mit Deiner Restriktion nicht mehr

In sicher 99 % alle FHEM Device geht das:
- Raw DEF öffnen
- alles kopieren
- in einen andere / neue Instanz gehen Raw DEF öffnen,
- alles einfügen
- ausführen - fertig!
2b) es gibt Geräte / Einbausituationen wo das eben nicht mal so einfach gemacht ist.

ZitatWarum sollte ich das drehen?

Damit die Logik wieder auf den Füßen steht, Du hast sie meiner Meinung nach auf den Kopf gestellt.

Gruß Otto

martinp876 · 05 Juli 2020, 12:03:24

Verstanden.
Raw Def habe ich bisher nicht betrachtet/bemerkt.
Die Implementierung von Raw Definition halte ich erst einmal für (sehr) fraglich - oder habe es noch nicht verstanden. Nicht aus Sicht des Users, aus Sicht der System-Integration.
### Meine Punkte / Philosophie
- Viel oder alles erlauben ist gut für Bastler, schlecht für "Anwender"
+ Baslter wursteln sich durch und müssen mit Problemen Lebel
+ Anwender brauchen Führung und Sicherheit. Für Module welche ich nicht maintaine wünsche ich mir das Dringend
=> Mögliche Fehler sind zu verhindern
- FHEM erlaubt sehr viel - es sollte aber Grenzen geben.
==> So mir nicht noch Details fehlen, welche ich noch suchen werde, ist das Fenster undurchdacht. Schade eingentlich, die Idee ist gut.
### Raw Def:
- was ist "Raw" an dieser Definition? Es wird schlicht die Definition identisch dem fhem.cfg in eine Komamndozeile kopiert - gefolgt von. den Readings (welche überaltert sind)? Raw ist da erst einmal nichts. Das Kopieren ist ein Vorteil
=> ich hätte schlicht die Zeilen mit <entity> aus dem Config ge-grept und in das Kommandofenster ge-pastet.
=> Das Raw-Fenster im Eingabe-modus ist schlicht ein Terminal-fenster mit multi-Command Option
=> Das Fenster ist nicht auf "define" begrenzt - der Titel ist also falsch
=> Die Ausführung deines Beispiels wirft bei mir den ersten Fehler, dass das IO nicht vorhanden ist (logisch). Ich muss also editieren.
. Lösche ich diese Zeile geht das Define schief, da es schon ausgeführt ist. => noch einmal editieren
. Dann bleibt es am Model hängen - mit der Response "modelForce" zu nutzen. nicht ok? Editieren musste ich schon mehrfach
. Sub-Type wird automatisch gesetzt - passt also
=> kopieren ich ein mehrteiliges Device (8-kanal-Schalter) wird es schon wieder schwierig. CUL_HM legt die 8 Kanäle an (was absolut sinn macht, weiche ich nicht ab!). Und nun willst du den 8-fach Schalter kopieren - natürlich mit 8 Kanälen. _> jetzt bist du dran... wie soll das gehen?
=> hast du schon einmal probiert, einen Kanal zu kopieren? So einfach ist das nicht....

#### Meine Vision / Anforderungen:
* Um ein Device aus CUL_HM zu kopieren muss ich alle Kanäle mitnehmen
* CUL_HM kann das kopieren unterstützen und ein Datenpaket zu Verfügung stellen. Nur CUL_HM kennt die Zusammenhänge (wie jedes andere Modul auch)
* Um ein Device zu "pasten", es also "nach-zu Konfigurieren", entsprechend dem fhem.cfg - kann man implementieren. CUL_HM kann gerne in einen "raw" Modus implementieren. Dazu muss das raw-definition Fenster diesen aktivieren.

===>> Nun hatten wir einen neuen Modus (z.B. "raw")

##> Das Kommando ist aus meiner Sicht fehlgeschlagen. Um es zu betreiben ist einiges (EINIGES) nicht beachtet. Es würde sich relativ einfach lösen lassen, wenn fhem-web nachbessern würde.

Otto123 · 05 Juli 2020, 13:04:43

Hallo Martin,

ca. 4 Jahre nach der Einführung der Raw Definition stellst Du deren Sinnfälligkeit in Frage?

Ob das Ding Raw Definiton oder "Willis Bastelbude" heisst spielt doch erstmal keine Rolle. Man findet einen Begriff für ein Tool, der Inhalt, Umfang usw. kann sich auch mal ändern. Man gibt dem Kind einen Namen ohne zu wissen was aus ihm wird wenn es erwachsen ist.
Die Funktion der mehrzeiligen Kommandozeile gibt es in Form der telnet Schnittstelle doch schon immer?
Die Anzeige in dem Fenster liefert keine veralteten Readings, es zeigt die Definition des Gerätes aus der aktuellen Config und den Inhalt des aktuellen statefile.
Letztlich führt Raw Definitonen einen kleinen Auszug aus der config zur Laufzeit aus. Aus meiner Sicht muss das genauso funktionieren wie zum Start von FHEM auch.
Wie es vom Prinzip her funktioniert hat Rudi hier mal kurz beschrieben.
Raw Definition ist aus meiner Sicht eines der wichtigsten Mittel beim sicheren Umgang mit FHEM gerade für Anwender. Ich finde nicht, dass Raw Definition ein Modus für Bastler (Insider) ist

Gruß Otto

martinp876 · 05 Juli 2020, 15:25:40

Ich habe es vorher nicht gesehen, nicht gebraucht, nicht vermisst und nicht hinterfragt. Faktisch ist mir egal wie alt es ist.
Ich habe es gerne, wenn der Name Programm ist. Weder raw noch define passen. Define zum teil, ok.
Mein telnet client kann mehrzeilig, andere auch. Ist also kein added value für mich, ich gebe dir recht.
Natürlich sind die readings bei EXPORT aktuell. Der IMPORT findet aber an einem andere gerät zu einem anderen Zeitpunkt statt. Somit veraltet beim import. Ich würde die readings IMMER weglassen.
Das mit dem auszug ist mir klar. Das mit dem funktonieren zur Laufzeit: klares nein. Ich räume nach dem init auf, komtrolliere attribute und abhängigkeiten, welche der kernal mir unsortiert vor die Füsse wirft. Readings mit referenzen zu nicht mehr vorhandenen entities machen keinen sinn. Kanäle werden angelegt.... Wie machst du das?
Rudis erklärung werde ich mir ansehen. Wenn es nur eine Erklärung für Anwender ist kann ich es mir sparen. Das kann man nach 2min überreissen.
Im letzten punkt habe ich keine Meinung. Ich habe es bislang nicht vermisst, tue es noch immer nicht. Mir ist der usecase immer noch unklar. Für culhm sehe ich in der anwendung einige probleme, nicht nur "model" sondern auch kanäle.
Ich bin gerne bereit, rawdefine zu unterszützen. Auf der aktuellen basis wird es nicht funktionieren.

Die aktuelle basis ist für bastler. Sie für Anwender sollvoll zu gestalten wäre mein anliegen. Culhm kann nicht sehen, dass rawdef ausgeführt wird.