Verwendung von KI bitte immer deutlich kennzeichnen

[ignis-draco]

@MartinP

Ich würde sagen, es kommt darauf an, was man selbst baut.
Wenn man nur fertige Adapter nimmt und diese an Geräte (z.B. heatingcontrol) anschließt, dann macht es das Ganze nur übersichtlicher, mehr aber auch nicht. Wenn man aber selbst Scripte schreibt (oder Blockly) dann würde ich sofort damit anfangen. Die ersten Scripte von mir sind entstanden als es noch keine Aliase gab. Da habe ich teilweise mit Whitespaces und festen Pfaden gearbeitet. Wenn ich ein neues Gerät hatte oder ein Gerät geändert habe musste ich das an 4-5 Stellen anpassen. Da hätte ich schon beim zweiten Gerät von der Struktur profitiert. Nicht ohne Grund habe ich alle Skripte so überarbeitet, dass ich nur noch mit einem Selektor auf die Geräte zugreife. Wenn ich jetzt eine neue Lampe kaufe, binde ich die z.B. per Zigbee ein, lege den Alias an und schon ist die Lampe zeitgesteuert gedimmt und per Telegramm steuerbar ohne das ich auch nur eine Zeile im Quellcode ändern muss.
Also wenn man vorhat selbst Skripte zu bauen (was meiner Meinung nach der Hauptgrund ist ioBroker zu verwenden) dann sollte man gleich am ersten Tag damit anfangen um keine Altlasten aufzubauen.

[da_Woody]

@martinp sagte in Welche Namen haben Eure Sensoren/Aktoren?:

Die Frage ist, wann man mit dem Nutzen von Aliasen anfängt.

IMHO gleich von anfang an!
kann mich noch gut erinnern, wie wir damals zu zweit 2 tage gesessen sind und für jeden alias, damals noch über das script, jeden alias manuell angelegt haben. ein vertipper, nochmal. frustrierend... :(
mit dem aliasmanager ist das leben schon einfacher geworden...

[MartinP]

@da_woody Habe erste Versuche gemacht, mit den "Konvertierungsfunktionen"...

Habe "mqtt.0.thermostat.sensors.raum.temperature" meines Thermostaten ge-aliast und EIGENTLICH die Temperatur. die im Alias angezeigt wird als Fingerübung von °C in Kelvin konvertieren lassen ...

Plötzlich sah der Grafana-Graph des Thermostaten etwas komisch aus (Wohlgemerkt aus dem original-datenpunkt gespeist mqtt.0.thermostat.sensors.raum.temperature) ...

Da muss ich mich wohl noch einmal damit beschäftigen, wie der reale Datenpunkt und sein Alias miteinander interagieren ...

[MartinP]

So richtig wird dieser Alias-Adapter wohl nicht mein Freund - meine Celsius<->Fahrenheit Kelvin Experimente haben den ioBroker LXC-Container in 100% CPU und Speicher getrieben ...
Mal schauen, wie ich aus der Nummer wieder herauskomme ...

NACHTRAG - Reboot des LXC-Containers und dann habe ich erstmal meine Alias-Basteleien wieder gelöscht, bevor sie noch Unheil anrichten...

NACHTRAG 2 - ich bin mir völlig im Unklaren, warum der Alias-Datenpunkt solche Rückwirkungen auf den ioBroker haben kann. Selbst die Konsole des LXC-Containers ließ sich nicht mehr bedienen... Von da her gibt es überhaupt keine Infos, welche Prozesse da Amok gelaufen sind.

Eigentlich braucht man für die Nutzung ja drei Arten von Aliasen:

1. Lesen eines Messwertes aus einem realen Datenpunkt
2. Schreiben eines Messwertes in einen realen Datenpunkt
3. Beides , z. B. wenn man den Schaltzustand einer Steckdose über ein Alias schreiben und auch auslesen will...

Würde wirklich gerne wissen, wie es zu diesem Amoklauf gekommen ist, und in welcher Weise da das Nutzen einer Umrechnungsfunktion für beide Richtungen eine Rolle gespielt hat. Die Rückwirkung der Umrechnung im Alias-Datenpunkt auf den Original-Datenpunkt finde ich auch sehr irritierend....

Legt der Alias-Adapter womöglich gar keine "Schatten" Datenpunkte an, sondern arbeitet sich irgendwie an den verknüpften Original-Datenpunkten ab?

[ignis-draco]

@MartinP

Kann es sein das du eine Endlosschleife gebaut hast ?

1. gerät schreibt in "mqtt.0.thermostat.sensors.raum.temperature"
2. "mqtt.0.thermostat.sensors.raum.temperature" hat einen neuen Wert
3. der umgewandelt wird
4. der neue Wert wir in z.b "alias.0.dev.local_temp_kelvin" geschrieben.
5. es gibt einen neuen Wert in "alias.0.dev.local_temp_kelvin"
6. Dieser Wert wird umgewandelt
7. der neue wert wird nach "mqtt.0.thermostat.sensors.raum.temperature" geschrieben
8. "mqtt.0.thermostat.sensors.raum.temperature" hat einen neuen Wert und es geht mit 3 wieder los.

Lass mal die write Funktion weg. Bei mir läuft das in einem LXC mit nur read seit heute morgen 6 Uhr ohne Probleme.

Ich finde es übrigen sehr komisch das du eine DP sowohl lesend als auch schreibend verwendest.
Normaler weiße hat gibt es doch immer eine set und eine current oder so.

P.S. An die die sich besser damit auskennen könnte es sein das bei dem schreiben von
"mqtt.0.thermostat.sensors.raum.temperature" nach "alias.0.dev.local_temp_kelvin" das ack auf True gesetzt werden muss?

[MartinP]

@ignis-draco said in Welche Namen haben Eure Sensoren/Aktoren?:

Ich finde es übrigen sehr komisch das du eine DP sowohl lesend als auch schreibend verwendest.
Normaler weiße hat gibt es doch immer eine set und eine current oder so.

Habe geschaut - weder im Sonoff-Adapter für die NOUS A1T Tasmota Steckdose, noch in der Fritz!DECT 200 gibt es diese Trennung ...

Die ESP8266 Firmware für den Thermostaten habe ich selber programmiert - da hätte ich die Freiheit, das zu ändern ...

Der Alias-Adapter scheint sich ganz schön genau umzuschauen ...

Habe den Alias-Punkt für die Raumtemperatur gestern komplett gelöscht, und gerade wieder angelegt ...

Da gibt es einen Verweis auf die Influx-DB - trotzdem die EIGENTLICH Direkt auf den original-Datenpunkt schaut - das würde ggfs. die Rückwirkung erklären ...

{
  "type": "state",
  "common": {
    "name": "thermostat/sensors/raum/temperature",
    "role": "variable",
    "type": "number",
    "read": true,
    "write": true,
    "alias": {
      "id": "mqtt.0.thermostat.sensors.raum.temperature"
    },
    "custom": {
      "influxdb.0": {
        "enabled": true,
        "storageType": "",
        "aliasId": "Raumtemperatur-ArbeitszimmerMartin",
        "debounceTime": 0,
        "blockTime": 0,
        "changesOnly": true,
        "changesRelogInterval": 0,
        "changesMinDelta": 0,
        "ignoreBelowNumber": "",
        "disableSkippedValueLogging": false,
        "enableDebugLogs": false,
        "debounce": 1000
      }
    }
  },
  "_id": "alias.0.Arbeitszimmer.temperature",
  "native": {},
  "from": "system.adapter.admin.0",
  "user": "system.user.admin",
  "ts": 1700128067582,
  "acl": {
    "object": 1636,
    "state": 1636,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator"
  }
}

Was soll mit klicken von entsprechendem "x" gelöscht werden?

"Konverter beim Schreiben" oder oben den Haken bei "unterschiedliche IDs ..:" setzen und "Alias write State" Löschen?

[MartinP]

Habe es erstmal so probiert - das "x" weggemacht

Amoklauf bleibt bisher aus ;-)

Nachtrag - bei dieser Lösung gibt es trotzdem Rückwirkung auf die Grafana-Grafen

Nachtrag 2. mit "Unterschiedliche ID verwenden", und Aus-Xen der Schreib-ID gibt es eine Fehlermeldung...

[MartinP]

So, diese Lösung scheint die Schleife zu vermeiden - geschrieben wird aber in den extra angelegten Userdata Dummy-Datenpunkt in Userdata nicht ...

EDIT: Auch in diesem Szenario gibt es Rückwirkungen auf die influx-DB und die Grafana Darstellung ...

EDIT2: Ich HASSE Assistenten...

Der Alias hat irgendwie AUTOMATISCH die Influx-DB Parametrierung vom Mutter-Datenpunkt kopiert- oder die Datenstrukturen hinter dem Alias sind so schlicht ... :

Es könnte auch eine Fehl-Interpretation von "lesen" und "schreiben" vorliegen

[MartinP]

So, nachdem ich die Influx-Verknüpfung im Alias-Datenpunkt gelöscht habe, ist erstmal Ruhe.

Im Endausbau wird es sicherlich sinnvoll sein, von den Alias-Datenpunkten aus in die Influx-DB zu schreiben. um es z. B. bei Geräteaustausch auch an der Influx Front leichter zu haben...

Habe dann noch im Common-Reiter des Alias-Bearbeiten-Fensters die Haken Readable und Writeable gefunden, und den letzteren abgeschaltet

[DJMarc75]

öööhm, geht es noch um das Thema vom Beitragstitel ? ;)

[MartinP]

@djmarc75 Jedenfalls war ich inspiriert vom Thema des Beitragstitels, als ich Aliases ausprobiert habe, und die Erfahrungen mit der Sperrigkeit des Themas gemacht habe. Hätte auch damit enden können dass meine Antwort gewesen wäre "ihre Geburtsnamen", weil ich den Alias-Adapter für zu riskant erfahren hätte....

Die Überschrift kann man schon als relativ allgemeine Bitte um Erfahrungen mit dem Alias-Adapter (der aber gar nicht in der Überschrift erwähnt wird) gelesen werden...

EDIT: Auch nicht im Hinterkopf des Fragestellers bei der Threaderöffnung war ....

[Ein ehemaliger Benutzer]

@pi-ter

Bei mir ist die name convention relativ einfach: <art><device><raum><no.> also Plug_Ventilator_BueroB_1 damit weiss ich, wo was gemeint ist. Die IP etc ist erstmal unwichtig, da sich diese aendern kann, arbeite der einfachheit gern mit dhcp-servern und dns, wenn ich den Name weiss, ist mir die IP egal.

[Ein ehemaliger Benutzer]

@martinp sagte in Welche Namen haben Eure Sensoren/Aktoren?:

Der Alias hat irgendwie AUTOMATISCH die Influx-DB Parame

Moin,

ja, steht auch da!

Unter optionen:

Wenn man da den Haken wegnimmt, dann sollte da erst gar nichts angelegt werden.

VG
Bernd

[MartinP]

@ilovegym Das ist EIN Bandwurm-Name für ein Gerät. Über den Alias-Adapter würde man das ggfs. so machen ...

Alias.0.Erdgeschoss.BueroB1.Ventilator.Power

Dass es ein Zwischenstecker ist, der den Ventilator steuert, ist erstmal irrelevant, und braucht auf dieser Ebenen nicht zu interessieren. Vielleicht gibt es - wenn der Ventilator mal kaputt geht Ersatz, der eine integrierte Fernsteuerfähigkeit hat, und deshalb keinen Zwischenstecker mehr braucht...

[Ein ehemaliger Benutzer]

@martinp

Hmm ich hab über 500 Devices, da möchte ich gerne wissen, nach was ich suchen muss… ;-)

Aber jedem seine Philosophie ..

[MartinP]

Es muss ja nicht nur ein Ordnungssystem geben - man kann ja mehrere Alias-Bäume anlegen, die verschiedene Baum-Strukturierte Sichten auf die Geräte bzw. Datenpunkte bieten.

.... oder den eigentlichen Namen des Gerätes nach Deinem Schema anlegen, und dann trotzdem einen Alias-Baum darüberlegen ...

Wenn man z. B. das Raum-Thermometer einmal als MQTT-Device hat, und in einem anderen Raum das Thermometer in einer FritzDECT Dose nutzt, wird es z. B. mühsam, ein allgemeingültiges Skript für beide Thermometer anzulegen ...