HM-Analyser für Windows - CCU-Analyse-Tool

[Tibin]

Moin BadenPower,
Danke für die wie immer hilfreiche Erklärung.
Gruß Tino

[.Keks]

...

Du meinst bestimmt die Auswahlmöglichkeit zwischen "CCU-konforme" und "HM-Internals konforme"- "Analyse/Reparatur?


Bei der "CCU-konforme Analyse/Reparatur" werden die Objekte nach den Regeln der CCU untersucht und repariert, also so, wie sie original sein sollten.

Die "HM-Internals-konforme Analyse/Reparatur" berücksichtig geänderte Objekteigenschaften und Erweiterungen, welche zum Beispiel vom HM-Administrator gesetzt oder erzeugt werden, um zusätzliche Funktionalität zu erzeugen, welche in der CCU-WebUI nicht vorhanden sind.


viele Grüße
BadenPower
.

Guten Abend BadenPower,

ich habe ja noch das Analysetool in Version 1.0.0b ohne Erweiterungen wie oben beschrieben in Version 1.0.2b,
aaaaber
kann es sein dass in 1.0.0.b bereits schon "Vorläufer" der 1.0.2b tätig waren (obwohl Repaeratur noch in 1.0.0b "Reparatur" ausgegraut?

Mich macht zur Zeit (wenn denn Zeit ist... Du kennst meine Sanierungssituatiuon) folgenses ein bissel stutzig:

Ich habe einen HmIP-SMI Bewegungsmelder seit Anfang des Jahres auf Test-CCU2.
Er ist also durch unterschiedliche CCU-Firmwareversionen "mitgezogen".

Nun habe ich einen weiteren HmIP-SMI in Betrieb genommen (gleicher Firmwarestand wie "Walking BWM") un in der Zwischenzeit mit Deinem Tool gearbeitet.
Dieser meldet sich in der UI gänzlich anders, denn statt 2 Felder zeigt dieser nun 5.....

Diese 3 weiteren Einträge sind "eigentlich" Bestandteil der HmIP-SMI55 Bewegungsmelder, auch nur, wenn der BWM in den Geräteeinstellungen auf "Netzbetrieb" umgeställt "wäre".
Von den HmIP-SMI55 habe ich 2 Stück, jedoch im "Batteriebetrieb"

Bei dem SMI funktioniert das Feld "Bewegungserkennung ausschalten" jedoch nicht.
Der Button "Reset Status" allerdings funktioniert tadellos und der Sensor springt auf "keine Bewegung erkannt".

K.A. ob das mal wieder von der "Jugend forscht Abteilung" unwissend eingebaut wurde, kann mir jedefalls nicht erklären, woher die zusätzlichen Buttons/Felder in der UI kommen, die der HmIP-SMI eigentlich nicht haben dürfte.


VG .Keks

[BadenPower]

Hallo .Keks,

die Analysefunktion der 1.0.0 ist die gleiche wie in der 1.0.2 mit der Einstellung "CCU-konform".

Das nächste General-Update wird so in 2-3 Wochen fällig werden. Tibin hat im Moment den Versionsvorteil eines "Frischlings", da er eine Stable-Entwicklungsversion hat.

Da bei der Analyse aber nichts geändert wird und die Reparaturfunktion bei Dir noch nicht aktiviert ist, ist es unwahrscheinlich, dass die Änderungen durch die Analyse kommen.

Führe einmal die Analyse durch und poste das Ergebnis.

Da ich keine IP-Gräte habe kann ich das Anzeigeverhalten nicht rekonstruieren.
Kannst Du von den 3 betroffene Geräten einmal mit dem HM-Investigator die Datenpunkte aller Kanäle der Geräte auslesen?

Wichtig wären die Datenpunktmethoden:
.Name()
.Enabled()
.Internal()
.Visible()
.Operations()

und die Kanal-Methoden:
.Name()
.Enabled()
.Internal()
.Visible()

Dann kann ich das Ganze einmal mit der Datenpunktdokumentation vergleichen


viele Grüße
BadenPower
.

[.Keks]

Guten Morgen,

ich konnte mir das auch nicht vorstellen, aber da das Kompetenzzentrum ja die IP-Dinger meist erst bei der 2. oder 3. Firmwareverion "rund" bekommen (Fiasko bei HmIP-SMO, HmIP-SMI, HmIP-FROLL, Durchgangssensor wartet ja auch noch auf Fix, usw.) vermute ich eher die Beule kommt aus Leer.

Wir hatten ja auch die "Leichen" in der CCU, die von dem HmIP-PSM stammen. Dieser läuft allerdings auch wieder (allerdings nach mehreren Reboots) scheinbar ordentlich.

IP habe ich nur genommen, da die Dinger ja OTAU können und nicht wie die Klassik-Variante eingeschickt werden muss, damit neue Firmware drauf kommt.
Kommt bei der "obersten Heeresleitung" nicht so gut, wenn man die UP-Dosen offen mit fliegender Verdrahtung rumhängen lässt, während die Aktoren eingeschickt sind.

Da kannte ich dieses Forum noch nicht und wie es scheint, ist es über fhem möglich es selbst durchführen zu können (in meinem Fall die HM-Classic UP-Aktoren Rollladen und Dimmer)

Da Du keine IP-Geräte hast, kann ich Dir da gerne die Dinge für Deine weitere Arbeit von meinen Geräten zukommen lassen, sofern Du möchtest.

Machen wir doch wieder ein How-To für das WIKI für die von Dir benötigten Datenpunkte und Kanäle im HM-Investigator


viele Grüße
.Keks

[.Keks]

Guten Abend,

nachdem ich die v 1.0.2b des HM-Analysers bekommen habe, kam ich jetzt endlich dazu das Tool in dieser Version zu testen.

Der neue Punkt "Programme" ist absolut genial!
Ich kann da nur mutmaßen, worauf das hinausläuft und das es Bestandteil des HM-Administrators sein wird, aber "Hut ab, Respekt und Anerkennung".
Ein solches Tool würde den Großteil aller Fragen zu "nicht funktionierenden Programmen" vermeiden.
Bin mal gespannt wann es nachgebaut wird.

Hatte letzte Woche einen HmIP-SMI55 mit einem UP-Netzteil ausgestattet und das Luder zickte rum und war weg, nachdem ich den Betrieb auf "Netzbetrieb" in den Geräteeigenschaften stellen wollte.

Die HmIP-SMI's haben zwar die Buttons, aber  "Bewegungserkennung ausschalten" kann zwar betätigt werden, hat jdoch keinerlei Auswirkung.

Die HmIP-SMI55, bekommen die zusätzlichen Buttons (Bewegungserkennung ausschalten & Reset Status) ja erst in der UI, wenn diese auf "Netzbetrieb" in den Eigenschaften gestellt werden.

Duch etwas "Stress" habe ich das Dingen einfach verdrängt und während Sanierung achtet man auf andere Dinge, als auf ein nicht mehr aktiven Bewegungsmelder.

Daher im Analyser dann die entsprechenden Einträge in dem zugehörigen Programm (rote Pfeile), da das Dingen ja weg ist.

Jetzt muss ich nur noch herausfinden, was das Kompetenzzentrum aus Leer in den Energy-Counter-Programme der PSM/FSM's hineingebastelt hat.
Wie wäre da jetzt mit dem HM-Investigator die Vorgehensweise (Wiki?)


Viele Grüße
.Keks

[BadenPower]

Der neue Punkt "Programme" ist absolut genial!

Hallo .Keks,

Der neue Punkt "Programme" ist absolut genial!

Der wird noch besser, wenn irgendwann alle vorhanden Analysen und Reparaturmechanismen eingebaut sind.

In den beiden Screenshots hast Du noch Programme welchen einen "falschen Operatortyp" als Fehler auswerfen.
Kannst Du da einmal einen Screenshot eines Programmes machen und hier einstellen?

Über den HM-Investigator ist es tatsächlich auch möglich das Programm und dessen Struktur komplett auszulesen.
Dies gehört aber schon in die Klasse gehobener Fortgeschrittener.

Ich dachte ich käme Anfang der Woche dazu, den versprochenen Wiki-Beitrag zu den Geräten mit dessen Kanälen und deren Datenpinkte zu machen, hat mir aber leider nicht gereicht und bis zum Wochenende ist schon wieder alles verplant. Sorry

Den Wiki für das Programmeauslesen würde ich dann gerne hinten anstellen, da dieser auch eben auch die Kinder- und Kindeskinder-Abfragen aufbaut.


Habe aber in Deinem Sceenshot bemerkt, dass ich die zwei Schalflächen für die Analyse der Programmbedingungen und Programmaktionen nicht vollständig deaktiviert habe. Da liegen noch keinen aufrufbaren Funktionen dahinter und sollten daher nicht aktiv werden, wenn irgendeine Abfrage fertig ist..
Das passiert leider, wenn man eine Entwicklungsversion herausgibt.

Da Du auch die Entwicklungsstufe hast, kannst Du vielleicht Dir das einmal anschauen:
https://forum.fhem.de/index.php/topic,82954.msg850332.html#msg850332

Hier hat Tibin ein Problem, wenn er die Formatierungseinstellungen auf "komplette Formatierung" stellt.
Ich kann das Problem leider nicht nachstellen.


viele Grüße
BadenPower
.

[.Keks]

Guten Morgen BadenPower,

werde ich heute erst am Abend schaffen, das Problem ggf nachzustellen.
Da gleich im Zuge der Sanierung der Parkettboden zum 2. mal vorbereitet wird und ich heute auch noch ein Fahrzeug für Prüfstand vorbereiten muss.
Wenn die Sanierung abgeschlossen ist, schließe ich mich ein und schmeiß den Schlüssel weg, damit Reccourcen für Erarbeitung des Status "Fortgeschrittener" frei werden
Somit genügend Baustellen neben HM und kein Zeitdruck von meiner Seite.

Viele Grüße
.Keks

[BadenPower]

Jetzt muss ich nur noch herausfinden, was das Kompetenzzentrum aus Leer in den Energy-Counter-Programme der PSM/FSM's hineingebastelt hat.

Ich habe nochmals in meinen Unterlagen geblättert und einige Tests gemacht und komme zu dem Entschluß, dass Du Dir hierum keine Sorgen machen mußt.

Es handelt sich um systeminterne Programme, welche automatisch von der CCU angelegt werden.
Beim Anlegen der Programme werden 3 Flags entgegen den Regeln der Programmerstellung per WebUI gesetzt und so eine problemlose Änderung per WebUI verhindert.

Ich habe die ausgegebene Meldung für diese Art von Programmen vorerst einmal von "Fehler" auf "Info" heruntergestuft. 


viele Grüße
BadenPower
.

[.Keks]

...
Ich habe die ausgegebene Meldung für diese Art von Programmen vorerst einmal von "Fehler" auf "Info" heruntergestuft. 
.

Danke Dir!


viele Grüße
.Keks

[Tibin]

Hallo BadenPower,
ich muss mal wieder dein Programm loben. Ohne den Analyser hätte ich den Fehler wohl nicht so schnell gefunden.
Das Setup: gestern im SysLog ein Fehler .....

Code Auswählen Erweitern

Nov  9 07:36:00 homematic-ccu2 local0.err ReGaHss: Error: IseSingleCondition::GetValData - invalid object ID [iseCondition.cpp:695]
konnte ich nix mit anfangen....
heute 07:38   der gleiche Fehler, wieder kein Plan, also suchen....
Das einzige was ich mit Google zu diesem Fehler gefunden habe war:

Ich schaue mir das Programm an und stelle fest. ODER Systemvariable Wert.... Also da ist die Systemvariable verschwunden

Immer noch kein Plan...
Analyser angeschmissen.... siehe Bild "Analyser"
Programm kontrolliert.... siehe Bild "Prg mit Fehler"
da gibt es tatsächlich eine fehlerhafte ODER-Bedingung mit einer Systemvariablen. Das beunruhigende daran: da stand vorher Geräteauswahl! siehe Bild "Original"
Und dieses Programm läuft schon ewig ohne dass ich da was geändert habe.
Die einzige Änderung die es gestern gab, war dass der Stromzähler getauscht wurde und die ccu2 neu gestartet wurde.

Hast du eventuell eine logische Erklärung für so ein Verhalten?
Gruß Tino

[BadenPower]

Hallo Tino,

eine logische Erklärung für dieses Phänomen habe ich leider nicht.
Ich sehe nur, dass es nicht um eine originale CCU2-Firmware handelt.

Da aber dieser unvorhersehbare Umstand, vor allem beim Einsatz von RaspberryMatic, bekannt ist, habe ich diese Analysen ausgearbeitet um eben schnell solche Fehler zu finden.

In Deinem 1. Screenshot ist zu erkennen, dass Dir der HM-Analyser 8 Fehler ausgibt. Der 1. Fehler ist leider nicht zu erkennen.
Die Fehlermeldungen der "fehlerhaften Operatorentypen" kannst Du ignorieren, denn diese habe ich inzwischen zu Informationen "degradiert", da es sich um interne vom System angelegte Programme handelt, welche dies so handhaben.

Das Programm "prgEnergyCounter_2616_000855699C3797:7" weist einen Fehler aufgrund einer fehlenden Bedingung in der 1. Bedingungsgruppe auf, welche die 2 anderen "prgEnergyCounter_XXXX" nicht haben.

Hier würden mich einmal die Screenshots dieser Programme interessieren.
Kannst Du auch nochmals nachschauen, was der 1. gefundene Fehler war?

Laut Fehlerausgabe müßtest Du 3 Energieerfassungsgeräte angemeldet haben. Eventuell sind es auch 4, wenn sich der 1. Fehler auch auf ein "Energiezählergerät" bezieht.
Kannst Du einmal die Seriennummer der tatsächlich vorhandenen Geräte gegenchecken?


viele Grüße
BadenPower
.

[Tibin]

Hallo BadenPower,

Ich sehe nur, dass es nicht um eine originale CCU2-Firmware handelt

Wie meinst du das? siehe Bild "FWccu2"

In Deinem 1. Screenshot ist zu erkennen, dass Dir der HM-Analyser 8 Fehler ausgibt. Der 1. Fehler ist leider nicht zu erkennen

hier nochmal komplett   siehe Bild "Analyser"

Hier würden mich einmal die Screenshots dieser Programme interessieren

siehe Bild "prgEc2616" mit zugehörigem Skript:

Code Auswählen Erweitern

object chn = dom.GetObject('2616');
object oOverflow = chn.DPByControl('POWERMETER_PSM.ENERGY_COUNTER_OVERFLOW');
object oEnergyCounter = chn.DPByControl('POWERMETER_PSM.ENERGY_COUNTER');
object oSysVarEnergyCounter = dom.GetObject('svEnergyCounter_2616_000855699C3797:7');
object oSysVarEnergyCounterOldVal = dom.GetObject('svEnergyCounterOldVal_2616');
boolean overFlowFlag = oOverflow.Value();
real devVal = oEnergyCounter.Value();
real devValMax = oEnergyCounter.ValueMax();
real oldDevVal = oSysVarEnergyCounterOldVal.Value();
real diffVal = 0.0;
real sysVarVal = oSysVarEnergyCounter.Value();
integer tmp_devVal = (devVal.ToString().ToFloat() * 1000).ToInteger();
integer tmp_oldDevVal = (oldDevVal.ToString().ToFloat() * 1000).ToInteger();
if (overFlowFlag == false) {
! Normal conditions
if (tmp_oldDevVal <= tmp_devVal) {
diffVal = devVal - oldDevVal;
}
! Device has rebooted
if (tmp_oldDevVal > tmp_devVal) {
diffVal = devVal;
}
} else {
!overFlow is true
if (tmp_oldDevVal > tmp_devVal) {
! An device overflow has occured
diffVal = (devVal + devValMax) - oldDevVal;
} else {
! Once the overflow flag has been set it will only be false when the device reboots
! Therefore this is the normal condition after an device overflow
diffVal = devVal - oldDevVal;
}
}
oSysVarEnergyCounterOldVal.State(devVal);
oSysVarEnergyCounter.State(sysVarVal + diffVal);


siehe Bild "prgEc2623" mit zugehörigem Skript:

Code Auswählen Erweitern

object chn = dom.GetObject('2623');
object oOverflow = chn.DPByControl('POWERMETER_PSM.ENERGY_COUNTER_OVERFLOW');
object oEnergyCounter = chn.DPByControl('POWERMETER_PSM.ENERGY_COUNTER');
object oSysVarEnergyCounter = dom.GetObject('svEnergyCounter_2623_000855699C3797:7');
object oSysVarEnergyCounterOldVal = dom.GetObject('svEnergyCounterOldVal_2623');
boolean overFlowFlag = oOverflow.Value();
real devVal = oEnergyCounter.Value();
real devValMax = oEnergyCounter.ValueMax();
real oldDevVal = oSysVarEnergyCounterOldVal.Value();
real diffVal = 0.0;
real sysVarVal = oSysVarEnergyCounter.Value();
integer tmp_devVal = (devVal.ToString().ToFloat() * 1000).ToInteger();
integer tmp_oldDevVal = (oldDevVal.ToString().ToFloat() * 1000).ToInteger();
if (overFlowFlag == false) {
! Normal conditions
if (tmp_oldDevVal <= tmp_devVal) {
diffVal = devVal - oldDevVal;
}
! Device has rebooted
if (tmp_oldDevVal > tmp_devVal) {
diffVal = devVal;
}
} else {
!overFlow is true
if (tmp_oldDevVal > tmp_devVal) {
! An device overflow has occured
diffVal = (devVal + devValMax) - oldDevVal;
} else {
! Once the overflow flag has been set it will only be false when the device reboots
! Therefore this is the normal condition after an device overflow
diffVal = devVal - oldDevVal;
}
}
oSysVarEnergyCounterOldVal.State(devVal);
oSysVarEnergyCounter.State(sysVarVal + diffVal);


siehe Bild "prgEc4129" mit zugehörigem Skript:

Code Auswählen Erweitern

object chn = dom.GetObject('4129');
object oOverflow = chn.DPByControl('POWERMETER_PSM.ENERGY_COUNTER_OVERFLOW');
object oEnergyCounter = chn.DPByControl('POWERMETER_PSM.ENERGY_COUNTER');
object oSysVarEnergyCounter = dom.GetObject('svEnergyCounter_4129_000858A994CF05:7');
object oSysVarEnergyCounterOldVal = dom.GetObject('svEnergyCounterOldVal_4129');
boolean overFlowFlag = oOverflow.Value();
real devVal = oEnergyCounter.Value();
real devValMax = oEnergyCounter.ValueMax();
real oldDevVal = oSysVarEnergyCounterOldVal.Value();
real diffVal = 0.0;
real sysVarVal = oSysVarEnergyCounter.Value();
integer tmp_devVal = (devVal.ToString().ToFloat() * 1000).ToInteger();
integer tmp_oldDevVal = (oldDevVal.ToString().ToFloat() * 1000).ToInteger();
if (overFlowFlag == false) {
! Normal conditions
if (tmp_oldDevVal <= tmp_devVal) {
diffVal = devVal - oldDevVal;
}
! Device has rebooted
if (tmp_oldDevVal > tmp_devVal) {
diffVal = devVal;
}
} else {
!overFlow is true
if (tmp_oldDevVal > tmp_devVal) {
! An device overflow has occured
diffVal = (devVal + devValMax) - oldDevVal;
} else {
! Once the overflow flag has been set it will only be false when the device reboots
! Therefore this is the normal condition after an device overflow
diffVal = devVal - oldDevVal;
}
}
oSysVarEnergyCounterOldVal.State(devVal);
oSysVarEnergyCounter.State(sysVarVal + diffVal);


siehe Bild "prgEc17593" mit zugehörigem Skript:

Code Auswählen Erweitern

object chn = dom.GetObject('17593');
object oBoot = chn.DPByControl('POWERMETER.BOOT');
object oEnergyCounter = chn.DPByControl('POWERMETER.ENERGY_COUNTER');
object oSysVarEnergyCounter = dom.GetObject('svEnergyCounter_17593_LEQ0540251:2');
object oSysVarEnergyCounterOldVal = dom.GetObject('svEnergyCounterOldVal_17593');
var bootFlag = oBoot.Value();
var devVal = oEnergyCounter.Value();
var devValMax = oEnergyCounter.ValueMax();
var oldDevVal = oSysVarEnergyCounterOldVal.Value();
var diffVal = 0.0;
var sysVarVal = oSysVarEnergyCounter.Value();
var tmp_devVal = (devVal.ToString(3).ToFloat() * 100).ToInteger();
var tmp_oldDevVal = (oldDevVal.ToString(3).ToFloat() * 100).ToInteger();
if (oldDevVal <= 0) {
oSysVarEnergyCounterOldVal.State(devVal);
oSysVarEnergyCounter.State(devVal);
} else {
if ( ( bootFlag == true ) && ( tmp_devVal < tmp_oldDevVal ) ) {
diffVal = devVal;
} else {
if (tmp_devVal >= tmp_oldDevVal) {
diffVal = devVal - oldDevVal;
}
if (tmp_devVal < tmp_oldDevVal) {
diffVal = (devVal + devValMax) - oldDevVal;
}
}
oSysVarEnergyCounterOldVal.State(devVal);
oSysVarEnergyCounter.State(sysVarVal + diffVal);
}


prgEnergyCounter_2616 und 2623 gehören zu einem HmIP-BSM
prgEnergyCounter_4129 gehört auch zu einem HmIP-BSM
prgEnergyCounter_17593 gehört zu einem HM-ES-PMSw1-Pl

wobei bei den ersten beiden wohl ein Fehler existiert, oder?

Gruß Tino

[Tibin]

Auf den ersten Blick würde ich sagen, beim ersten Programm wurde die Bedingung geklaut und das Programm automatisch neu angelegt
Bei nochmaliger Überlegung glaube ich aber dass ich dieses Gerät vor längerer Zeit ab und neu anlernen musste, da es nicht mehr reagiert hat.
Könnte mir vorstellen, dass das zugehörige Programm beim Ablernen des Aktors irgendwie nicht gelöscht wurde.
Aber sind alles nur Vermutungen.
Gruß Tino

[BadenPower]

Hallo Tino,

Wie meinst du das? siehe Bild "FWccu2"

Anhand des Screenshots des Programmes aus Deinem vorherigen Post sieht man bei "RolladenWohnzimmerrechts" in der Bedingung den Vergleichsoperator "im Wertebereich / mit Wert". Dies deutet auf einen Patch der Firmware hin.

wobei bei den ersten beiden wohl ein Fehler existiert, oder?

Ja, denn die 1. Bedingung sollte auch einen Auslöser enthalten.

ABER:

Da es sich bei 2616 und 2623 um die gleiche Seriennummer handelt läßt dies den Schluß zu, dass das Objekt 2616 eine alte ID ist und nicht mehr zum ursprünglichen Gerät gehört. Da es sich um ein IP-Gerät handelt ist womöglich ein Geräte-Firmwareupdate mit anschliesendem notwendigem Ab- und Anlernen des Gerätes ursächlich.

Prüfe das Vorhandensein des Objektes mit der ID 2616 im HM-Investigator unter "Komplexe Abfragen" -> "Objekte", oder im HM-CodeEditor mit

Code Auswählen Erweitern


WriteLine(dom.GetObject(2616));

Die Vermutung ist, dass dieses Objekt nicht mehr existiert oder durch ein anderes Objekt bereits wieder überschrieben wurde.

Leider exisiert immernoch der Bug, dass diese Programme nicht automatisch gelöscht werden.

Falls das Objekt nicht mehr existiert, dann kannst Du das Programm "prgEnergyCounter_2616_000855699C3797:7" auch löschen, da es nicht mehr benötigt wird und beim Reboot unnötig und fälschlicherweise eine Aktion (Skript) ausführt.

Auf den ersten Blick würde ich sagen, beim ersten Programm wurde die Bedingung geklaut und das Programm automatisch neu angelegt
Bei nochmaliger Überlegung glaube ich aber dass ich dieses Gerät vor längerer Zeit ab und neu anlernen musste, da es nicht mehr reagiert hat.
Könnte mir vorstellen, dass das zugehörige Programm beim Ablernen des Aktors irgendwie nicht gelöscht wurde.
Aber sind alles nur Vermutungen.

Alles richtig erkannt.


viele Grüße
BadenPower
.

[Tibin]

Hallo BadenPower,
mit dem Investigator kommt bei 2616:

Code Auswählen Erweitern

HmIP-RF.000855699C3797:5.STATE   2616   HSSDP

und bei 2623:

Code Auswählen Erweitern

HmIP-BSM 000855699C3797:7   2623   CHANNEL

Hätte jetzt bei der 2616 irgendwie existiert nicht oder so erwartet... mmh.
Ich würde das Programm trotzdem löschen, oder?
Vielleicht ist das auch der letzte Zustand den das Objekt hatte bevor es gelöscht wurde?

Gruß Tino
PS: habs jetzt gelöscht, dir einen schönen Restsonntag noch. Diese IP-Geräte