... und weil ich auch gern mal was an die Community zurückgeben möchte: Wer Bedarf an Rainbird-Icons bzw. allgemein Icons für die automatische Gartenbewässerung hat, kann ich gern diese vier zur Verfügung stellen:

Rain Bird RSD-BEx Regensensor | Getrieberegner | Sprühregner | Tropbewässerung

In Verbindung mit dem Material Design von @Uhula lassen sich Statusmeldungen (z.B. "Regen erkannt" oder "Bewässerung Zone X läuft") wunderbar durch "glühen" oder "blinken" (Beispiele sh. unterer Zeile) darstellen.

Icons als PNG im Spoiler

@Feuersturm : Ja, das sind grundsätzlich die beiden gängigen Wege, die mir bekannt sind. Zwei Grafiken übereinander versuche ich jedoch zu vermeiden. Deshalb bevorzuge ich i.d.R. den Weg über Bindings.
Allerdings musst Du nicht noch den Umweg mit einem Skript und separaten Datenpunkt machen.
Am Beispiel des Regensensor-Icons könntet Du ins Feld "CSS-Klasse" nämlich direkt folgendes eintragen: {val:rainbird.0.device.sensors.rain;val=="true"? "mdui-blue-pulse": " "}

Den ein oder anderen Tipp findest Du vielleicht auch noch in den Antworten auf meine diesbezüglichen Fragen im "Material Design CSS für ioBroker.vis"-Thread: Link 1 / Link 2

@ioBrockerNewbee: OK, dann lag ich mit meiner Vermutung doch daneben. Müssen wir abwarten bis @StrathCole eine fundierte Aussage dazu machen kann.

Vielen Dank für die Übernahme des Adapter in den Community-Bereich. Nach dem ich den ganzen Sommer gezögert hatte, war ich nun nach dem Update vom js-Controller auf 6.0.11 "gezwungen" bei diesem Adapter auf die neue Version 1.0.1 umzusteigen.

Neben dem Dank an @StrathCole und @mcm1957 möchte ich gern bestätigen, dass diese Version bei mir erfolgreich mit einem Rainbird "ESP-RZXe" (mit LNK Wifi) funktioniert.
Nach welchen Kriterien darf der ins stable-Repo? Dort sollte er m.E. nun hin.

@michael-6
Gerne werde ich Dich mit Tests und Feedback unterstützen. Ist gerade zeitlich etwas eng bei mir. Meine iob-dev-Instanz läuft aber "nur" im Docker-Container. Habs dort noch nicht probiert - denke aber mit der Python-Installation auf Probleme zu stoßen....

Hallo zusammen,

nach dem ich mein "Wasserzähler-Projekt" ein Jahr liegen gelassen hatte, wollte ich es diesen Herbst erneut angehen.
Die Welt hat sich inzwischen natürlich weitergedreht und z.B. der mir vom @MartyBr empfohlene Stick IM871A ist nun gar nicht mehr verfügbar. Stattdessen wird dort ein iU891A-XL angeboten. Ist der auch geeignet? Hat jemand mit dem Erfahrungen?

Alternativ hätte ich mir auch den hier im Forum u.a. von @Freaknet und @PeterSCP erwähnten und von smart-home-komponente.de angebotenen CUL "FTDI CC1101 868MHz M-Bus" bestellt. Gerade bin ich aber über eine relativ junge Rezension von 'Christian B.' auf amazon stutzig geworden, wo der Stick ebenfalls vom gleichen Anbieter zu haben ist.
Er schrieb dort am 13. September 2025:
"[...] nicht zum Empfangen der Daten eines Diehl Hydrus 2.0 per wM-Bus. Problem hierbei ist, dass der Wasserzähler 200 - 250 Bytes sendet, der nanocul allerdings nur 148 bytes Spitze zu verarbeiten schafft. [...]"

Kann hier jemand bei der Aufklärung helfen? Ist das so? Wer hat den "nano CUL 868 MBUS" von smart-home-komponente.de im Einsatz?

Laut „Netzwerkkarte“ hat der schon wieder keine Verbindungslinie mehr, obwohl er seit dem letzten Pairing vor fünf Tagen zumindest keine Fehlalarme mehr auslöst und nach wie vor zuverlässig auch bei Bewegung funktioniert.

Ich setze den Thread auf „gelöst“ und werde bei nächster Gelegenheit mal die Batterie tauschen.

@arteck
Falls ich mich wirklich missverständlich ausgedrückt habe:

• 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

@homoran
OK, hast Recht. Ich schau mal unter den Sensor…
RTCGQ11LM - ist genau der, wie erkannt.

@arteck
Ausschließen kann ich es nicht - halte es aus persönlicher Erfahrung mit der Zigbee-Reichweite doch für sehr unwahrscheinlich. Mein direktes Nachbarhaus hat definitiv keine Zigbee-Geräte (oder sonstige 'smarte' Komponenten) im Einsatz. Das Nachbarhaus über die Straße ist locker 25 m von meinem Koordinator entfernt plus mind. 2 dicke Außenwände und kleine Fenster. Ich habe ja schon Empfangsprobleme mit Sensoren, die ich selbst außen "nur" 4-5 Meter von der Hauswand entfernt platziert habe.

Ich werde aber tatsächlich bei Gelegenheit mal nachfragen. Das interessiert mich schon. Auch wenn ich es für unwahrscheinlich halte, da sie m.W. auch komplett Fußbodenheizung haben und somit ebenfalls keine Verwendung für ein Heizkörperthermostat hätten.

Aber mal angenommen das wäre so: In welchen Fällen konnte sich ein fremdes Gerät mit meinem Netzwerk verbinden? So selten und kurz, wie ich den Pairing-Modus aktiv habe. Noch dazu: Wie kommen mir völlig unbekannte Namen in die 'LocalOverrides.json'? Ich habe es so verstanden, dass dort nur selbst vergebene Namen landen.

Edit: Habe gerade mal nach ME167 und TRVZB gegoogelt. Das sind ja offensichtlich auch alles Heizkörperthermostate. Also mind. 3 verschiedene, die mal bei mir drin waren.

@haselchen: Das mit dem neun Anlernen war auch mein erster Gedanke und hatte ich schon mal gemacht, kurz bevor ich diesen Beitrag eröffnet hatte.
Einen Batteriewechsel hatte ich auch schon in Erwägung gezogen, auch wenn noch 100% zurück gemeldet werden (ich weiß - da kann man sich nicht drauf verlassen) wollte ich das als nächstes angehen.
In das Pairen hatte ich aber wenig Hoffnung gesetzt, da der Sensor ja bei Bewegung wie gewohnt funktioniert hat. Lediglich in der Netzwerkkarte wurde keine Verbindungslinie zu einem Koordinator dargestellt. Ich meine schon öfter von @Asgothian gelesen zu haben, dass die Netzwerkdarstellung nur bedingt aussagekräftig ist und man nicht so viel Wert drauf legen sollte, solange alles funktioniert. Auf meiner 'Netzwerkkarte' sehe ich auch noch zwei drei weitere Fenster und Temperatursensoren, die schon lange keine Verbindungslinie mehr haben, aber nach wie vor zuverlässig arbeiten. Bitte korrigiert mich, wenn ich das falsch in Erinnerung habe.
Durch das neue Pairing am Samstag wurde unbemerkt das DB-Logging des Datenpunkts deaktiviert. Deshalb kann ich jetzt nur eine Aussage für die Nacht von Sonntag auf Montag treffen: da waren keine ungewollten Auslöser mehr zu erkennen. Könnte also schon geholfen haben.

Ich beobachte das noch ein paar Tage und dann kann ich den Thread sicher wieder schließen. Ich danke Euch schon mal!

@arteck: Im Adapter wird mir die Modellnummer RTCGQ11LM angezeigt.

Hallo liebe ioBroker-Community,
vielleicht hat das von Euch schon mal jemand beobachtet und hat eine Erklärung dafür. Via Google bin ich zumindest nicht zu diesem Phänomen fündig geworden.

Ich betreibe sein einigen Jahren zu meiner vollsten Zufriedenheit u.a. mehre dieser kleinen batteriebetriebenen Bewegungsmelder im Zigbee-Netzwerk.

Bei einem hab ich während einer mehrtägigen Abwesenheit mal eine Fehlauslösung beobachtet. Das ist sicher verkraftbar, solange die nicht für Alarmierungszwecke genutzt werden.

Was mich aber seit ein paar Wochen beschäftigt, ist der in der Küche. Nach viel Monaten zuverlässigem Dienst schaltet der sich jetzt regelmäßig kurz allein auf true und somit die angesteuerte Beleuchtung ein. Hab das Umschalten mal eine Weile mitgeschnitten. Vor allem nachts, wenn keiner rumläuf, sieht man die Regelmäßigkeit sehr deutlich: Alle ca. 45 min (manchmal auch schon nach 42 oder 43 Minuten) schaltet der einmal auf true und nach 1:30 min wieder auf false. Hatte den auch schon mal zur Wand gedreht, um äußere Einflüsse auszuschließen. Macht der trotzdem.

Hat jemand noch einen Tipp für mich?

@asgothian
OK, danke für den Tipp. Hab ich gemacht. Lief alles wieder fehlerfrei an. Werde es nun weiter beobachten.

Hallo @Asgothian,
heute Morgen habe ich noch etwas weiter geforscht und folgende Erkenntnisse hinzugewonnen zu denen ich gern Deine Meinung wüsste:

Ich habe mir im Ordner /opt/iobroker/iobroker-data/zigbee_0 die Dateien

• nvbackup.json
• LocalOverrides.json und
• shepherd.db

angeschaut. Dabei ist mir aufgefallen, dass in der 'nvbackup.json' fünf Geräte aufgeführt werden, die ich gar nicht besitze und auch nie besessen habe. Lediglich den 'f0d1b8000015541c ' (SmartPlug) hatte ich früher einmal. Zudem werden in der 'LocalOverrides.json' sogar zu zwei dieser Geräte Alternativbezeichnungen vorgehalten.
In der 'shepherd.db' kommt derzeit keine der unten in der Tabelle genannten ieee's vor. (sicher auch weil ich gestern die zwei 'undefined' über den Adapter gelöscht hatte)

Quelle: nvbackup.json		Quelle: LocalOverrides.json	Quelle: persönliche Aufzeichnungen
ieee			nwk	Bezeichnung			Bezeichnung
f0d1b8000015541c	f617	<kein Eintrag>			LEDVANCE SmartPlug
84ba20fffe28ba94	6a61	<kein Eintrag>			TS0601_thermostat_3
540f57fffe760fbc	fee0	<kein Eintrag>			undefined
003c84fffebdd3ff	5f9f	ME167	
28dba7fffe741692	98f6	TRVZB	

Kann ich die unbekannten Geräte einfach von Hand aus den Dateien entfernen oder mache ich da mehr Schaden?

@asgothian
Das ist interessant. Ich erinnere mich! Vor länger Zeit wurde mir tatsächlich ein mir unbekanntes 'Thermostat' (sogar mit Bildchen) angezeigt. Und dabei habe ich gar keine smarten Thermostate im Haus (und Zigbee schon gar nicht) und habe ich auch nie besessen. Ich habe das damals auch mehrmals gelöscht, bis es irgendwann nicht wieder kam. Aber möglicherweise ist jetzt bloß kein Bildchen und kein Name mehr da. Den Namen habe ich mir damals leider nicht gemerkt oder notiert, drum kann ich jetzt nicht sagen, ob es genau das von Dir genannte war.

In meinen Unterlagen finde ich gerade eine Notiz, dass der 'undefined' 0x84ba20fffe28ba94 mindestens im April 2023 schon mal aufgetaucht ist. Ich weiß - das hilft jetzt auch nicht weiter. Aber offenbar besteht das "Phänomen" schon deutlich länger, als mir vorhin bewusst war.