ESPHome - Name von Sensornamen

[WolfgangFB]

@klassisch
Wenn ich im yaml den Namen eines Sensors ändere, dann ändert sich die ID. Was ich auch nicht nachvollziehen kann: Ich werde nicht benötigte IDs nicht mehr los. Ich kann die löschen so oft ich will, der ESPHome Adapter legt mir immer alle jemals verwendeten IDs wieder an. Wie kann ich das verhindern?

[klassisch]

@wolfgangfb sagte in ESPHome - Name von Sensornamen:

Wäre es nicht möglich, diese "Namen" selbst zu vergeben? Der erste Teil 0.483FDA36363A ist die Mac Adresse des Teils, aber wie wird der 1951150879 Teil gebildet?

Wir könnten ja versuchen folgenden Änderungsvorschlag auf Github einzureichen:

The path and IDs of the data points were generated automatically according to the definition made by ESPHome and delivered by the ESPs.
The Ids follow this pattern:

esphome.<instance#>.<MAC-Address>.Sensor.<random#>.state

This is ok, as a default.

Would it be possible to implement an alternative pattern such as

<user defined path>.<name of the ESP>.<name of data point>.state

example: currently we have the following path and ID

leading to

esphome.0.8CAAB57ACB29.Sensor.3409894020.state

more convenient would be

0_userdata.0.moisture.hobbyroom.hobby-wall-moisture.Dew Point.state

with the correspondence / replacement:

The user defined path

0_userdata.0.moisture.hobbyroom

replaces

esphome.0

The name of the ESP

hobby-wall-moisture

replaces the MAC of the ESP

8CAAB57ACB29

and the name of the sensor data point

Dew Point

replaces the random ID#

3409894020

The descriptor

Sensor

can be dropped

[klassisch]

@wolfgangfb sagte in ESPHome - Name von Sensornamen:

@klassisch
Wenn ich im yaml den Namen eines Sensors ändere, dann ändert sich die ID.

Ja, genau

Was ich auch nicht nachvollziehen kann: Ich werde nicht benötigte IDs nicht mehr los. Ich kann die löschen so oft ich will, der ESPHome Adapter legt mir immer alle jemals verwendeten IDs wieder an. Wie kann ich das verhindern?

Hast Du die alten Teile in der Instanzenansicht des Adapters gelöscht?

[e-s]

@klassisch
Kannst du bitte einen PR erstellen, ich finde den Vorschlag super. Vielleicht kann @Dutchman etwas dazu sagen.

[klassisch]

@e-s sagte in ESPHome - Name von Sensornamen:

Kannst du bitte einen PR erstellen,

Wenn ich git richtig verstanden habe, dann bräuchte ich für einen Pull request Code. Aber ich bin kein Programmierprofi.
Ich könnte einen issue aufmachen und diesen Vorschlag einbringen.

ich finde den Vorschlag super.

vielen Dank, man muß sich dann halt darüber im Klaren sein, daß man dann halt für die Kollisionsfreiheit selbst verantwortlich ist. Aber das wäre es mir wert.

Vielleicht kann @Dutchman etwas dazu sagen.

Ja, das wäre prima. Könnte ja sein, daß er keine Zeit dafür hat, oder die ganze Sache zu umfangreich würde oder wir etwas generelles übersehen haben.

[WolfgangFB]

@klassisch said in ESPHome - Name von Sensornamen:

@wolfgangfb sagte in ESPHome - Name von Sensornamen:

@klassisch
Wenn ich im yaml den Namen eines Sensors ändere, dann ändert sich die ID.

Ja, genau

Was ich auch nicht nachvollziehen kann: Ich werde nicht benötigte IDs nicht mehr los. Ich kann die löschen so oft ich will, der ESPHome Adapter legt mir immer alle jemals verwendeten IDs wieder an. Wie kann ich das verhindern?

Hast Du die alten Teile in der Instanzenansicht des Adapters gelöscht?

Was meinst Du damit?
Ich habe sie bei "Objekte" aus dem Baum esphome.0 gelöscht. Bei den Instanzen kann ich nur ganze Devices löschen.

[klassisch]

@wolfgangfb Ja genau. Wenn Du so ein Device umbenannt hast, dann solltest Du das alte device in der Instanzenansicht des Adapters löschen. Danach kannst Du auch die Objekte dieses alten Devices löschen.
Bei den aktiven Devices werden alle Datenpunkte angelegt, die im YAML definiert sind.

[WolfgangFB]

@klassisch
Hi

Das stimmt zumindest bei mir so leider nicht. Ich habe eine neues yaml erstellt und installiert. Es wird bei den Objekten ein Baum erstellt der unter anderem state mit dem Namen "Name1" hat. Jetzt gehe ich in die Instanzen von ESPHome, lösche das gesamte Device (damit wird automatisch bei den Objekten alles von diesem Device entfernt, auch "Name1". Jetzt gehe ich in yaml, benenne den Sensor von "Name1" in Name2" um, speichere und schreibe auf den ESP und anschließend habe ich in den Objekten 2 states, einmal "Name1" und einmal "Name2". Wie werde ich Name1 los?

[klassisch]

@wolfgangfb Bin nicht sicher, ob ich sowas schon mal hatte, weil ich eher erweitere als rückbaue.
Aber Bei Dir hat der Adapter das Device unter dem selben Devicenamen mit name 1 und name 2 "gesehen". Du hast ja das Device und die Objekte gelöscht, während der ESP noch mit name 1 lief. Er könnte sich dann beim Adapter gemeldet haben während Du neu übersetzt hast. Der Adapter hätte dann name 1 gesehen und registriert.
Ich würde es so versuchen:

• Neues ymal ohne den name 1 erstellen
• übersetzen hochladen, laufen lassen
• ESP stoppen
• Objekte löschen
• Device löschen
• Nochmals kontrollieren. Alle Objekte weg?
• Adapter neu starten und prüfen, ob die Objekte noch immer weg sind (wahrscheinlich unnötig, hilft aber evtl. bei der Fehlersuche)
• ESP neu starten
• warten bis die Objekte befüllt sind. kommt name1 jetzt immer noch?

[WolfgangFB]

@klassisch

OK, mit einem Stoppen des ESP Adapters ist jetzt tatsächlich Name1 weg (mal sehen wie lange
Wie ist das wenn ich den ESP Adapter stoppe, dann kommen in der Zeit auch keine aktualisierten Sensorwerte (von anderen ESP Devices) an, richtig?

Was mich jetzt auch stutzig macht: Ich spiele schon den ganzen Mittag mit verschiedensten ESPs rum, der aktuelle (der mit dem Name1 Problem), hat keinen "Info" Baum. Nach welchen Kriterien wird der angelegt bzw. nicht angelegt?

[klassisch]

@wolfgangfb sagte in ESPHome - Name von Sensornamen:

OK, mit einem Stoppen des ESP Adapters ist jetzt tatsächlich Name1 weg (mal sehen wie lange

Aber Du hast den Adapter mittlerweile wieder neu gestartet?

Wie ist das wenn ich den ESP Adapter stoppe, dann kommen in der Zeit auch keine aktualisierten Sensorwerte (von anderen ESP Devices) an, richtig?

Ja, der Adapter arbeitet dann nicht und der ist der Ansprechpartner für die ESPs

Was mich jetzt auch stutzig macht: Ich spiele schon den ganzen Mittag mit verschiedensten ESPs rum, der aktuelle (der mit dem Name1 Problem), hat keinen "Info" Baum. Nach welchen Kriterien wird der angelegt bzw. nicht angelegt?

Keine Ahnung, bei mir haben alle einen Info-Baum.

[Dutchman]

was ihr auch da wünscht verstehe ich, kan ich aber kaum umsetzen...
Wir brauchen immer eine separate ID im object baum von ioBroker, dies muss fest sein.

ESPHome generiert selber die so genannte entity ID, warum die sich bei einer kleine aendderung (wieder der name in der YAML) auch ändert kan ich nicht erklären kommt halt von ESPHome und werden die auch nicht aendern.

Um name als id's zu übernehmen ist auch gefährlich, im gründe habe wir damit genau dasselbe problem erneut (man ändert den namen in ESPHome und es wird ein neuer state..... also nix geholfen :)) zudem entsteht das risico von sonder Zeichen die wieder einiges kaputt machen in object Strukturen

[klassisch]

@dutchman sagte in ESPHome - Name von Sensornamen:

Um name als id's zu übernehmen ist auch gefährlich, im gründe habe wir damit genau dasselbe problem erneut (man ändert den namen in ESPHome und es wird ein neuer state..... also nix geholfen :))

Doch schon - zumindest im Normalzustand. Dann wären die IDs sprechend, was sie jetzt leider nicht sind. Wenn man die Werte z.B. in FLOT nutzen möchte, ist das derzeit umständlich.

zudem entsteht das risico von sonder Zeichen die wieder einiges kaputt machen in object Strukturen

Ja, Sonderzeichen sind aergerlich. Auch so ein Thema, welches man bei der Rechtschreibreform vor 25 Jahren vergessen hat: Eliminierung der Sonderzeichen.

Ich waere da aber recht lieblos und wuerde alle Sonderzeichen einfach skippen.
Also aus "Küche" wuerde ich einfach "Kche" machen. Das wurden die user sicher schnell merken - und vermutlich einen neuen CR schreiben, der den Entwickler wieder unnoetig beschaefitigt

[Dutchman]

@klassisch sagte in ESPHome - Name von Sensornamen:

@dutchman sagte in ESPHome - Name von Sensornamen:

Um name als id's zu übernehmen ist auch gefährlich, im gründe habe wir damit genau dasselbe problem erneut (man ändert den namen in ESPHome und es wird ein neuer state..... also nix geholfen :))

Doch schon - zumindest im Normalzustand. Dann wären die IDs sprechend, was sie jetzt leider nicht sind. Wenn man die Werte z.B. in FLOT nutzen möchte, ist das derzeit umständlich.

zudem entsteht das risico von sonder Zeichen die wieder einiges kaputt machen in object Strukturen

Ja, Sonderzeichen sind aergerlich. Auch so ein Thema, welches man bei der Rechtschreibreform vor 25 Jahren vergessen hat: Eliminierung der Sonderzeichen.

Ich waere da aber recht lieblos und wuerde alle Sonderzeichen einfach skippen.
Also aus "Küche" wuerde ich einfach "Kche" machen. Das wurden die user sicher schnell merken - und vermutlich einen neuen CR schreiben, der den Entwickler wieder unnoetig beschaefitigt

Denke mal genau dafür sollte man alias erstellen damit ist die Hardware/Sensor auch austauschbar und ist der Name immer für jeden frei definierbar

[WolfgangFB]

@dutchman
Ich mache das jetzt auch mit Aliasen.
Bin jetzt dazu übergegangen, die Namen der Sensoren nach folgendem Schema zu vergeben

binary_sensor:
  - platform: gpio
    pin: D2
    name: "D2.state Bewegung 1 motion"

D2 ist der Pin ".state" was es ist (könnte z.B. auch ".temperature" sein). Die letzten 3 Werte sind dafür, was das ganze später steuern soll.

Dann habe ich mir ein Skript geschrieben, dass alle ESPs in meinem System sucht und bei denen, bei denen die Namen nach diesem Schema vergeben sind, 2 Aliase erzeugt. Eines um den ESP bequem abzufragen und eines für die Aufgabe.

var fs = require('fs'); 
const Fn = "/opt/iobroker/Wolfgang/esphome2.txt";       
fs.writeFileSync(Fn, ''); 
const CrLf = String.fromCharCode(13) + String.fromCharCode(10); 
function Log(s){
    var AenderungszeitText = ""; //formatDate(getDateObject(new Date().getTime()), "DD.MM hh:mm:ss");         
    fs.appendFileSync(Fn, AenderungszeitText + "" +s + CrLf); 
    }
  
function FirstWord(OrigString){
    var OrigStringSplit = OrigString.split(" ");
    return(OrigStringSplit[0]);
    }
function FirstX(OrigName, Count){
    var OrigNameS = OrigName.split(".");
    var Result = "";
    for (var i = 0;i < Count; i++){Result = Result + OrigNameS[i] + ".";}  
    return(Result);
    }
function FirstXOhnePunkt(OrigName, Count){
    var OrigNameS = OrigName.split(".");
    var Result = "";
    for (var i = 0;i < Count - 1; i++){Result = Result + OrigNameS[i] + ".";}  
    Result = Result + OrigNameS[Count - 1];
    return(Result);
    }
    
const EspStates = $('esphome.0.*.state');  
var LastFirst3 = "";
var LastFirst4 = "";
var Raum = ""
var EspVersion = ".0.";
var AliasName = "D1";
for(var i = 0; i < EspStates.length; i++){
    var AktState =  EspStates[i];
    var ActFirst3 = FirstX(AktState, 3);
    if (LastFirst3 != ActFirst3){
        LastFirst3 = ActFirst3;
        Log("");
        var EspName = getState(ActFirst3 + "info.name").val;
        Log("ESP = " + EspName); 
        switch(EspName){
            case("sauna"):
                Raum = "Sauna";
                break;
            case("gallerie2"):
                Raum = "Gallerie";
                break;
            case("gast2"):
                Raum = "Gast";
                break;
            case("wohnen1"):
                Raum = "Wohnen";
                EspVersion = ".1.";
                break;
            }
        var EspAlias = "alias.0.Raum." + Raum + ".EspHome" + EspVersion + "alive";
        var CS = "createAlias('" + EspAlias + "', '" + ActFirst3 + "info._online', '');";  //esphome.0.8CAAB57CB1E6.info._online"
        Log(CS);
        } 
    var ObjectName = FirstXOhnePunkt(EspStates[i], 5);
    var obj = getObject(FirstXOhnePunkt(EspStates[i], 5));
    var CommonName = obj.common.name; 
    var CommonNameSplit = CommonName.split(" ");
    AliasName = FirstWord(CommonName);   
    
    if (AliasName.includes(".") == true)
        {
        Log("// " + CommonName); // 
        Log("// " + EspStates[i] + " " + getState(EspStates[i]).val);  
        // Alias ESPHome -> Raum      
        EspAlias = "alias.0.Raum." + Raum + ".EspHome" + EspVersion + AliasName;
        var FunktionAlias = "alias.0.Raum." + Raum + "." + CommonNameSplit[1] + "." + CommonNameSplit[2] + "." + CommonNameSplit[3];
        var CS = "createAlias('" + EspAlias + "', '" + EspStates[i] + "', '');"; 
        Log(CS);
        // Alias Raum -> Funktion
        CS = "createAlias('" + FunktionAlias + "', '" + EspStates[i] + "', '');"
        Log(CS);
        //Log("createAlias('alias.0.Raum.' + Raum + '.EspHome.0.' + EspStates[i], idOrigin, '');")
        }
    }

Als Ergebnis erhalte ich die Datei esphome2.txt in der dann z.B. folgendes steht

ESP = wohnen1
createAlias('alias.0.Raum.Wohnen.EspHome.1.alive', 'esphome.0.8CAAB57CB1E6.info._online', '');
// D5.state Fenster 1 opened
// esphome.0.8CAAB57CB1E6.BinarySensor.1094227559.state true
createAlias('alias.0.Raum.Wohnen.EspHome.1.D5.state', 'esphome.0.8CAAB57CB1E6.BinarySensor.1094227559.state', '');
createAlias('alias.0.Raum.Wohnen.Fenster.1.opened', 'esphome.0.8CAAB57CB1E6.BinarySensor.1094227559.state', '');

Alle createAlias Zeilen, die ich brauche, kopiere ich in ein zweites Skript, dass dann die Aliase erzeugt. (Das stammt hier aus dem Forum)

In meiner Vis Umgebung oder anderen Skripten greife ich nicht mehr direkt auf die ESP Datenpunkte sondern nur noch auf die Aliase zu. Damit is es relativ egal, wie oft die Namen von ESPHome geändert werden.