Verwendung von KI bitte immer deutlich kennzeichnen

[ignis-draco]

Hi,

um auf die ursprüngliche frage zurück zu kommen. Durch den Alias-Manager haben sich super Strukturierungsmöglichkeiten ergeben.
Da ich mit "meinem" System sehr zufrieden bin würde ich das mal vorstellen vielleicht hilft es ja jemanden sein eigenes zu entwickeln.
In meinen Skripten arbeite ich nur mit DP aus alias oder 0_userdata.
Durch ein Script habe ich mir einer die gleiche Ordner Struktur unter Alias.0 und 0_userdata erstellen lassen.

"<Etage>/<Raum>/<Gewerk>"

In alias kommen natürlich nur die DP von Geräten wobei ich darauf achte das die DP immer gleich lauten z.b brightness, current oder device_temperature. Unter 0_userdata werden dann zwischen Ergebnisse gespeichert z.b Welchen Dimmwert sollen die Lampen in einem Raum haben.
Wenn man jetzt noch den Name (common.name) sauber setzt ist es möglich in den Scripten nur noch mit selektoren zu arbeiten.
Mit z.b.

let current  = $('state[id=alias.0.*.load_power*]');

bekommt man eine Liste von alle Geräten die einen verbrauch in Watt haben.
Durch den path ist es dann Möglich sich den Raumnamen zu holen.
So kann man z.b. ein Telegram Menü bauen was alle Geräte verwende die im Alias sind.

   current.each(function(id, i) {
        var tmp = "aus";
        var state_path = id.replace("load_power", "state")
        if (getState(state_path).val === true){
            tmp = "an"

        }
        output += "\n<b>" + getRoomName(id) + ":</b>\n"
        output += getObject(id).common.name + "(" + tmp + ") = " + getState(id).val + "W\n"

        inline_keyboard.push([{ text: getObject(id).common.name + ' Ein', callback_data: main_call+ state_path + ";on" },
                { text: getObject(id).common.name + ' Aus', callback_data: main_call +  state_path+ ";off" }])
    })

Wenn man das bei allen Scripten so machen ist es kein Problem mehr Geräte Hinzuzufügen oder zu entfernen.
Auch brauch man so keine Komplizierte Name weil es egal ist was für ein Bewegungsmelder (Hardware, WIFI, bluetooth oder Totmannschalter ) Hauptsache es gibt einen DP mit den name "occupancy" der True wird wenn jemand da ist. Und durch die Ordner ist auch klar wo er sich befindet.

[MartinP]

@ignis-draco Ist die Struktur "von Hand angelegt"? Mussten z. B. die beiden Datenpunkte "room_temperature" und "humidity" (die ja anscheinend aus einem Gerät kommen) separat angelegt werden, oder hast Du das irgendwie automatisiert?

Jetzt wird es Philosophisch: Aber wahrscheinlich ist es prinzipiell nicht möglich, das zu automatisieren - wenn das nämlich ginge, wären die aliase nicht nötig ;-) Wahrscheinlich ist es wirklich am besten, sich da ein möglichst strukturiertes Schema auszudenken, und dann die Datenpunkte von Hand dort in das Schema einzupflegen ...

Probleme sehe ich noch, wenn die Geräte unterschiedliche Einheiten in ihren Datenpunkten verwenden. Die FritzDect Steckdosen schreiben den Verbrauch in kWh in ihren Datenpunkt, Tasmota in Wh ...

[ignis-draco]

@MartinP

Ja ich habe die alle per Hand angelegt. Ich kann mir nicht vorstellen wie man das Automatisieren soll.
Als Beispiel ich habe aktuell unterschiedliche Thermostate im Einsatz der DPs zum setzten der Wusch Temperatur sind:

zigbee2mqtt.0.0x1c34f1fffedbb33b.current_heating_setpoint
zigbee2mqtt.0.0x54ef44100074026c.occupied_heating_setpoint
maxcul.0.KEQ0447740.desiredTemperature

Wie man sieht ist selbst nicht mal bei Zigbee2mqtt die Benennung einheitlich. Ich könnte mir nur vorstellen das man vielleicht einen Wizzard baut der ein die Erstellung erleichter. Aber wie der genau aussieht hängt halt ganz stark von der gewollten Strucktur.

Die Order Struktur habe ich natürlich nicht von Hand angelegt.

Script

function createStruct()
{
    # Wo sollen die Ordner Strukturen erstellt werden ?  
    let paths = ["0_userdata.0", "alias.0"]
    let floors = new Object()
    # Welche Etagen und räume gibt es 
    floors["eg"] = ["outdoor","wc","office","kitchen","sleeping_room","living_room","hallway"]
    # Es können beliebig viele Etagen und Räume angelegt werden 
    #  floors["og"] = ["child_room1", "wc", "hallway", "child_room1"]
    
    # Welche Funktion soll in jedem Raum angelegt werden. 
    let func = ["light", "audio", "clima", "pressend","power","speak", ]
    func.sort();

    for(const base of paths){
        if(!existsObject(base)){
            console.log("base not exists!");		
        }else{
            for(const [floor, rooms] of Object.entries(floors)){
                rooms.sort()
                for(const room of rooms){
                    var path_tmp = base + "." + floor + "." + room
                   // if(!existsObject(path_tmp)){
                        setObject(path_tmp, {
                            type: 'folder',
                            common: {
                                name: room
                            },
                            native: {}
                        });
                    //}
                    for (const item of func){
                        let path2_tmp = path_tmp + "." + item
                      //  if(!existsObject(path2_tmp)){
                            setObject(path2_tmp, {
                                type: 'folder',
                                common: {
                                    name: item
                                },
                                native: {}
                            });                    
                     //   }
                    }
                }
            }
        } 
    }

   //  ##################### Userdata global ###############
    # Welche Ordner sollen dann im 0_userdata.0.global angelegt werden 
    let glob = ["radio", "timer", "refuel", "weather", "shopping", "clima"]; 
    glob.sort();
    if(!existsObject("0_userdata.0.global")){
         setObject("0_userdata.0.global", {
            type: 'folder',
            common: {
                name: "Global"
            },
            native: {}
        });
    }
    for(const item of glob){
        if(!existsObject("0_userdata.0.global."+item)){
         setObject("0_userdata.0.global."+item, {
            type: 'device',
            common: {
                name: item
            },
            native: {}
        });
        }
    }
    //  ##################### alias global ###############
    # Welche Ordner sollen dann im alias.0.global angelegt werden    
    let glob2 = ["audio", "clima"]; 
    glob2.sort();
    if(!existsObject("alias.0.global")){
         setObject("alias.0.global", {
            type: 'folder',
            common: {
                name: "Global"
            },
            native: {}
        });
    }
    for(const item of glob2){
        if(!existsObject("alias.0.global."+item)){
         setObject("alias.0.global."+item, {
            type: 'device',
            common: {
                name: item
            },
            native: {}
        });
        }
    }
}

createStruct();

Ach und die Sachen mit den unterschiedlichen Einheiten solange es man es umrechnen oder übersetzten kann lässt sich das hinbekommen. Z.b. Der device-reminder Adapter gibt bei einem gerät wenn es an ist "in action" raus. Für mich ist an der stelle ein True oder False besser. durch

val === 'in action' ? true : false

Das ich im "Alias Read-Function" eingetragen habe steht im DP ein true wenn "in action" ist ansonsten ein false.

[MartinP]

@ignis-draco Das Feature mit der meiner Meinung nach größten Sexyness wird als gegeben vorausgesetzt - dass man in den Aliasen auch Umrechnungsfunktionen ausführen lassen kann ist ja eigentlich ein sehr hilfreiches Feature. Sozusagen Hilfe bei Navigation, Organisation und Transformation ;-)

Alleine deshalb werde ich mich da wohl doch mal etwas genauer einlesen.
Die Frage ist, wann man mit dem Nutzen von Aliasen anfängt.
Ich habe nur meinen Heizkörperthermostaten und 4...5 Zwischenstecker. Dazu noch einen Smartmeter-Lesekopf, und ein Auslesescript für Fritzbox-Daten...

Aber vielleicht ist es nicht gut, zu warten bis der Leidensdruck zu groß wird ...

[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 ....

[A Former User]

@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.

[A Former User]

@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...

[A Former User]

@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 ...