NEWS

chatGPT5 ist soweit ganz ok, mit regexp kann man ihm nicht so ganz vertrauen und es scheint sich auch menschliche Angewohnheiten antrainiert zu haben.

sinngemäß
skynet: ich verstehe du möchtest im Lauftext rechts Luft haben, damit man den Anfang noch lesen kann. -> code ausgespuckt
ich: Nein, ich will die Luft links, weil der läuft nach links
skynet: Ah ich verstehe du willst die Luft links, das habe ich schon im vorherigen Beispiel berücksichtigt.

Gut, weiß also selbst nicht was es tut 😄

von heute:
skynet: Stimmt 👍 — beim Umsortieren habe ich Sand (RGB = { r: 237, g: 201, b: 175 }) übersehen.

Aha, fängt auch an schlampig zu werden

Zu 1. muß ich sagen, das ich mit meiner einfachen und funktionierenden Routine angefangen habe - und mit einer komplizierten mit Einstellungen überfrachteten Routine geendet bin - hab die 2 Stunden lang -> testen, debuggen, chatgpt anmeckern, code kopieren -> gehe zu testen ^^

@krissie777 sagte in ebus neuinstallation auf einem Debian Raspi:

Im IOBroker Adapter (abgefragte Datenpunkte) gebe ich welches: Gerät, in dem nach Parametern gesucht wird, ein?
Das -> 192.168.178.70:8888 ? Wenn ich das eingebe, kommt dieser Log:
received error! sent find, received ERR: element not found please check ebusd logs for details! find -c 192.168.178.70 -F circuit,name

An dieser Stelle die IP einzugeben, ergibt nun leider überhaupt keinen Sinn. Vielleicht solltest du dir noch kurz die Grundlagen der Kommunikation zwischen eBus-Koppler (esera), ebusd Service und Adapter erarbeiten.

Fragen zum Adapter würde ich hier

https://forum.iobroker.net/topic/9844/adapter-ebus

stellen. Ich nutze den Adapter nicht, sondern übermittele die Daten per MQTT, deshalb kann ich hier nicht weiter helfen.

@mcbert

Was ich aber nicht kapiere:

ich habe mir den ioBroker neu aufgesetzt, auf einen RaspberryPi5.

In welcher Anleitung steht denn bitte drin, das man einen root-Account freibuddelt?
Im üblichen Setup wird ja auch ein Standarduser und nix anderes angelegt. Da haste deinen user ganz automatisch von vorneherein schon fertig.

Man macht es so:

https://forum.iobroker.net/topic/51869/installation-auf-raspi-einfacher-geht-s-nicht

@asgothian
Danke für die schnelle Antwort.
Ich habe es nun so programmiert:

UND Verknüpfung.jpg

So funktioniert es.

Ich hatte kurz gedacht, es liegt daran, daß ich die IOS 26 Beta auf meinem Handy installiert hatte und mein Handy deshalb eine US-Zeitzone hat. Jetzt ist aber Berlin eingestellt.

Habe dann einmal das Handy auf NYC Zeit umgestellt. Dann crasht die App nicht sofort nach Eingabes des OTP. Bleibt aber hängen beim Hochfahren, "Verbunden mit Gerät oder Dienst" bleibt immer rot, die anderen beiden Punkte sind grün. Aber selbst 10 Minuten warten bringt nichts.
Also Kommando zurück.

Ich verstehe echt nicht, warum Amazon bei der Anmeldung denkt, ich sei in den USA. Ja, ich habe mich ab und zu auf Amazon-US verbunden, wenn man Links aus den US auf Amazon sehen will, dann schaltet die App das um. Habe ich aber immer sofort danach wieder auf DE und Euro gestellt.

Ich weiß jetzt wirklich nicht mehr, was ich wo einstellen soll/kann/muss. Jemand eine Idee?

Alternativ: gibt es ein einfach zu installierendes und zu nutzendes Spracheingabesystem, welches mir die gesprochene Eingabe als Text in ein IOBroker-Object sendet? Dann wäre ich den Alexa-Sch... endlich los, funktioniert sowieso alle paar Monate plötzlich für eine Weile nicht, weil die Amazonies wieder was abgeschaltet oder umgestellt haben.

@homoran
ja das passt, danke
ab dem 2. Element gibt es immer 3 führende Leerzeichen

@flkontakt said in SLS zu schwach dimensioniert für PV-Anlage. Was nun?:

Der Errichter der Anlage muss prüfen, welcher SLS eingesetzt werden muss/darf. Dafür die Tabelle der 4100 und mit der Fertigmeldung bestätigt der Elektriker, dass er sich an die VDE-Regeln gehalten hat.

Du unterschlägst die Prüfung der geltenden TAB am Netz des VNB. Die als Errichter außen vor zu lassen, keine gute Idee.
Das macht aber auch allzu defintive Pauschalaussagen für solche Geschichten genauso unsinnig wie lange ohne den Errichter zu aggieren. Der unterschreibt und haftet. Da kann man hier Purzelbäume machen. Es geht mir nur darum dem TE fundierte Dokumente für seinen Fall zu nennen mit denen er eine Lösung mit seinem Errichter besprechen kann. Darunter findet man beim VND im Umfeld der Tab sehr viel was zu tun oder zu lassen ist. Dazu noch Hilfen zum Verständnis wie sowas für eine PV-Anlage:
f2fd06f7-65f3-41c4-a4c1-9c5fc46d48fc-grafik.png

@mcm1957 sagte in RPI2 Adapter kann nicht installiert werden:

Wahrscheinlich kann man nur eine neue Major machen.

Oder einen Adater 'rpi13' oder so.

@oliverio
Rückinfo:
Adapter installiert über benutzerdefiniert.

url heißt: ... vis-mapwidgets
bei Adapter zu finden dann unter: Karten-Widgets

dann Instanz installiert (hat diesmal geklappt)
zu finden dann unter: vis-mapwidgets.0

Anmerkung:
Vielleicht sollte man zum leichteren Finden die Namen überall gleich halten.

In vis-1.edit findet man ein widget: mapwidgets

Soviel vorab.
Ich teste mal das widget und die Einstellungen

@bernhard-2
Weshalb so kompliziert?

Blockly_temp.JPG

Das liefert das gleiche Ergebnis:

Blockly_temp.JPG

Weshalb eine Hysterese von 900 W, wenn die maximale Leistung 600 W pro Stufe beträgt?

@thomas-braun

Ok, hab ich gemacht.

Danke dir erstmal für deine Hilfe!

@stefan341 das ist kein Wunder: du hast den Adapter im debug laufen. Damit flutet er das Log mit so vielen Nachrichten, dass du die entscheidenden Nachrichten nicht siehst.

Halte den Adapter bitte an, schalte ihn auf Info zurück, und starte ihn dann neu.
Am besten löscht du vor dem Starten noch das log, dann hast du wirklich nur die Meldungen vom Start im log und kannst die entscheidenden Meldungen schneller finden.

@bilberry sagte in ZigBee: 'undefined Devices' unbekannter Herkunft im Netzwerk:

mind. 3 der mir unbekannten Geräte in meiner Zigbee-Konfig sind Heizkörperthermostate
ich besitze aber weder Thermostate und hab auch nie welche bessen

Mindestens eine der Aussagen ist falsch.

Von alleine kommen die Geräte nicht in Dein Netz. Und da es sich bei den Geräten um TuYa Geräte handelt ist nicht einmal mehr sichergestellt das es sich um Heizkörperthermostate handelt - Sie haben sich halt nur mit den ID's von Heizkörperthermostaten gemeldet. Such mal unter https://www.zigbee2mqtt.io/supported-devices/ nach 'ts0601' und schau Dir an wie viele doch sehr wenig gleiche Geräte da gelistet werden - die alle melden sich initial als TS0601 - Erst durch Fingerprinting lassen die sich exakt identifizieren. Daher ist die Folgende Situation nicht unwahrscheinlich:

Jemand kauft ein TuYa Gerät Er versucht dieses mit dem Netzwerk zu verbinden - das klappt auch, aber das erkannte Gerät und das gekaufte Gerät passen nicht zusammen (kein passender fingerprint) Er nimmt das Gerät aus dem Netzwerk und schickt es zurück.
In diesem Fall verbleibt ein Eintrag in der dev_names.json (Absichtlich - die Datei dient ja gerade dazu das ein Gerät basierend auf seiner IEEE auch dann den gleichen Namen bekommt wenn ansonsten alles zurück gesetzt wurde.

Wenn man das mit betrachtet erscheint es unmöglich im Nachgang zu klären welches die falsche(n) Aussage(n) ist(sind).

Sicher ist:

Irgendwann haben sich Geräte mit den entsprechenden IEEE während des Pairings mit Deinem Netzwerk verbunden und sind entsprechend in der Shepherd.db (und nachfolgend der devnames.json) eingetragen worden. Zu diesem Zeitpunkt muss es auch die Objekte gegeben haben. Diese Geräte wurden wieder aus dem Netzwerk entfernt - entweder manuell durch einen Bediener oder durch eine device leave Nachricht vom Gerät selber.

Zum Thema Reichweite, Funknetz und so weiter:

Insbesondere bei Sensoren die mit Knopfzellen betrieben werden ist oft die Sendeleistung besonders gering um die Lebensdauer der Batterie zu erhöhen 2.4 GHz Funkwellen können durch Reflexion / Schwebung erstaunliche Reichweite erreichen - teilweise abhängig vom Wetter, von geparkten Autos oder anderen Effekten. Die Geräte können Zeitweilig irgendwo vorhanden gewesen sein (zum Test, o.ä.)

letztendlich bezweifle ich dass du dem wirklich auf den Grund gehen kannst. Was ich anbieten kann

Ab Version 3.1.x (wahrscheinlich 3.1.3, ggf. 3.1.2) kann der Adapter die Datenpunkte Zigbee.0.info.devicecount und Zigbee.0.info.groupount (beide neu, gibts aktuell noch nicht) befüllen, so das du einen Zeitlich zum hinzugefügten Device passenden Trigger bekommen kannst. Diese beiden DP werden aktualisiert:

bei jedem Start des Adpaters Wenn der Adapter ein neues Gerät einbindet Wenn der Nutzer ein Gerät(eine Gruppe) im Adapter löscht Wenn ein Gerät via device_leave das Netzwerk verlässt. Wenn der Nutzer eine Gruppe hinzufügt.

Dabei wird nicht garantiert das die Aktualisierung genau den Zeitpunkt trifft wo ein Gerät dem Netz beitritt - es wird der Zeitpunkt genommen an dem der Adapter dieses bemerkt. Und auch da ist es denkbar das zumindest am Anfang nicht alle Möglichkeiten dazu sauber erkannt werden.

A.

@mkaiser96 sagte in Dockerinstallation auf Synology Firewalleinstellungen:

@thomas-braun

Die letzte Einstellung soll ich also deaktivieren? Ich habe gedacht, wenn ich vorher die Ausnahmen zulasse, dass das Ganze funktionieren sollte.

Ich lasse doch alles eingehende zu den Ports 8081 und 1880 durch oder habe ich da ein Denkfehler?

Habe ich dadurch irgendwelche Sicherheitsrisiken, wenn ich den letzten Punkt deaktiviere?

Uh ja Denkfehler … Deine Firewall blockiert den Verkehr in beiden Seiten, ioBroker brauch schon Internet und DNS um Adapter installieren zu können.
Ergo Port 80/443 und 53 (DNS) müssen von innen nach außen freigeschaltet werden

Sind diese blockiert (was deine „alle“ rule macht) kommt halt nichts durch 😉

@ticaki
Ok, ich versuchs mal mit damit. Muss das erst mal durchschauen.

@OliverIO
Meinem "kleinen" llama Modell waren der Objektpfad sowie die Bezeichnung nicht ausreichend. Ein Pfad wie shelly.0.SHBDUO-1#XXXXXX.lights.Switch konnte nicht passend interpretiert werden. Auch die boolean Werte und Beschreibung wurde oft falsch interpretiert.
Deshalb habe ich diese in über die Datenpunkteinstellungen mit Beschreibung, Destination, Wert Boolean true und false, Unit, ... die Möglichkeit zum Definieren erstellt. Daraus wurde dann zb. Wohnzimmer Stehlampe ein, Temperatur Wohnzimmer 26°C oder Gute Nacht Geschichte Kinderzimmer.
Der Datenpunktpfad, Zeitstempel und die entstandene Beschreibung wurde dann an das Ollama Embedding Modell übergeben und in die Datenbank geschrieben. Bei einer Abfrage wurden die gespeicherten Daten dann abgefragt. Selbstverständlich würde sich dies auch mit Funktionen und Räume vordefinieren lassen.

Das Resultat daraus war, dass ich viel präzisere Antworten erhalten habe und auch ein kleines Modell diese relativ schnell verarbeiten konnte.

In Verbindung mit n8n könnte ich mir vorstellen, dass kurze Prompts wie:
Schalte die Stehlampe im Wohnzimmer ein. Direkt über ein Lokales Modell ablaufen könnte.
Größere und längere Anfragen wären mit einem externen Modell abzuarbeiten welchem die Daten zwar für den Prompt zur Verfügung gestellt bekommt, allerdings wären diese immer noch Lokal abgespeichert und nicht ausgelagert.

@peter-c

Ja. Wobei es RaspberryOS 13 'Trixie' noch nicht als stabile Veröffentlichung gibt.
Hier würde ich also noch ein paar Wochen abwarten, das dürfte nicht mehr allzulange bis zum offiziellen Release dauern.

@alterbastler sagte in Alarmanlage in VIS anzeigen:

Fast alle adapter sind jetzt bei 100 - 200 MB

Das sollte passen.
Der größte ist bei mir der Javascript-Adapter mit ~ 300 MB.
2 GB sind für einen Adapter auf jeden Fall zu viel.

@happyuser20 sagte in Probleme bei Temperaturwert über 100°C:

Ich habe den Bambulab Adapter vor längerer Zeit mal getestet. Wenn der aktiv war, stieg die Systemlast meiner Synology (dort läuft IOB im Container) dauerhaft auf 100% an.
Dann habe ich den Umweg über HASS gemacht.

interessant (bin der entwickler des adapter) derartiges verhalten ist mir nicht bekannt, wuerde mich freuen ueber mehr details

Edit: Es wurde auf github gemeldet, werde es mir anschauen sieht so aus alsob wir mehr messages bekommen wofuer ich einen buffer einbauen muss