Update platformio.ini | version adjustment #355
Conversation
# hardware structure revised # ESPcore update
# correction envNames
|
This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation. |
# update espressif32 to v6.6.0
# revised envName
|
Ich habe den Modellen extra ein "s" angehangen um die CC1101 Variante von der anderen "Simple oder Standard" unterscheidbar zu machen. |
Beziehst du das auf alle Kontroller? Edit: Nachdem ich mir deine Antwort noch einmal durchgelesen habe, denke ich zu verstehen was du meinst. Da würde ich denken, das es aber auch schnell zu einem Missverständnis kommen kann. Es gibt Bsp den ESP32s was einem NodeMCU https://docs.platformio.org/en/latest/boards/espressif32/nodemcu-32s.html entspricht. Wenn man diesen dann ohne CC1101 "beschriften" würde, so müsste dann das Kürzel ja ein doppeltes s sein. Vorraussetzung ich habe dich richtig verstanden. |
|
Wenn ich mich mal so richtig gut erinnern könnte. Das Problem ist, wenn es eine Firmware nano328 und nano328cc1101 gibt, dann soll die nano328 ja dort installiert werden, wo kein cc1101 ist. Aber im Namen nano328cc1101 steckt nano328 auch. Das ganze ist im Rahmen dieses commits passiert, in dem ich die Namen auch so angepasst habe, damit diese mit den erwarteten Namen im FHEM Modul übereinstimmen: Irgend einen Grund muss das Kürzel gehabt haben. |
|
Ich kann dich verstehen und auch das wir eine klare und eindeutige Zuordnung besitzen. Da stoße ich an den Punkt, das man alle Namen nach einem Schema haben sollte. Kommen wir überhaupt noch zu einem klaren Schema bzw. Attributnamen oder ist der Zug abgefahren zwecks kompatiblität? Ich füge mich dem ggf. auch und passe das Kleine "s" an in den Eventnamen. |
# revised names to names from attribute SIGNALduino Module # remove some commented out content
Ich glaube ein klares Schema kann nicht ohne Verluste erreicht werden, da der Name der Hardware in einem Attribut angegeben. wird und wurde. Darauf baut dann auch die Suche nach kompatibler Firmware auf. Hier stehen die Werte der Attribute. |
|
Hallo @sidey79
Das ganze Zusammenspiel kann ich mir denken und weiß wo alles zusammenspielt angefangen von Software Attribut bis hin zu Scripten oder einfach nur EventNamen beim Compiler. Der jetzige IST-Stand des PRs basiert auf eine Gleichheit der Attribute im FHEM Modul welche dann ebenso in PlatformIO bezeichnet sind. Somit würden wir erstmal keine Verluste machen bzw. keine Inkompatiblität herstellen. Die damalige Erkennungsmarke "s" oder "cc1101" sind vermutlich ungünstig gewählt. Das anzupassen auf die uC-Namen bringt mehr Anpassungen als gedacht. Man kann dies natürlich als Zukunftsgedanke belassen aber dann sollte man vorher das Schema definieren um es im FHEM Modul / uC Kompiler / AActions bzw. Scripte einheitlich zu haben. Als Softwareüberlegung wäre vielleicht ein Schönheitsfehler, das wir die uC im Modul die Reihenfolge |
# back to fixed version
(better clarity for the user)
(removal of fixed version information)
issues 353