Xiaomi Mi Pflanzensensor

AlCalzone

Bei der Neuanlage wird das JSON Common Name nicht erzeugt. `
Kann ich nicht nachvollziehen. Objektbaum gelöscht, Adapter gestartet und alles wird sauber angelegt - die States kommen nach einiger Zeit. Kannst du den Adapter in der Situation mal mit Loglevel "debug" starten und mir nen Logauszug schicken?

~~@malc:~~

ble.0 2018-03-24 14:03:28.607 error unhandled promise rejection: TypeError: Cannot read property 'device' of undefined `
Sollte mit 0.4.1 behoben sein. Dürfte aber auch nur auftreten wenn der Sensor nicht initialisiert ist. Stimmt das?

~~@malc:~~

bekam erst wieder Werte nachdem ich das Plugin von mi-flora auf xiaomi geändert habe. `
Kann ich nicht nachvollziehen. Kannst du den Adapter mal mit Loglevel "debug" starten und mir nen Logauszug schicken?

AlCalzone

~~@chka:~~

ich blicke echt nicht mehr durch, wann und vorallem was der sensor seine daten überträgt

ich habe unterschiedliche Zeiten von den Datenpunkte, die dann auch nicht im gleichen Intervall reinkommen.

Gibt es einen sync Intervall oder ist dies Glück

humidity: 22 true ble.0 2018-03-25 05:54:48.067

brightness: 209 true ble.0 2018-03-25 07:55:22.807

temperature: 20 true ble.0 2018-03-25 08:56:32.711

fertility: 311 true ble.0 2018-03-25 09:05:34.633 `

Der Sensor rotiert seine Daten. Ca. jede Sekunde kommt ein Paket, das je eine der Eigenschaften überträgt. Das ist dann ca. 10s lang das gleiche, dann wird die Eigenschaft gewechselt.

Der Adapter verwendet setStateChanged um den Wert in ioBroker zu setzen. D.h. es wird nur ein Wert in der History auftauchen, wenn er sich auch geändert hat.

chka

~~@AlCalzone:~~

Der Adapter verwendet setStateChanged um den Wert in ioBroker zu setzen. D.h. es wird nur ein Wert in der History auftauchen, wenn er sich auch geändert hat. `
Ah Kodas heißt dann aber auch das man nicht kontrollieren kann ob der sensor noch geht. oder alles passt. Kann man hier ggf einbauen das man zu mindestens alle Minute/Stunde sieht, ob der sensor überhaupt noch arbeitet. oder kann ich dies an einer anderen stelle sehen

chka

nachtrag: in der flower care app habe ich einen bodenfeuchtigkeitswert von 45% nach dem giessen, im BLE seit heute morgen keine Änderung 23%.

App ist wieder aus und es besteht sonst auch keine Verbindung zum sensor.

AlCalzone

~~@chka:~~

Ah Kodas heißt dann aber auch das man nicht kontrollieren kann ob der sensor noch geht. `
Doch, RSSI wird regelmäßig aktualisiert.

> in der flower care app habe ich einen bodenfeuchtigkeitswert von 45% nach dem giessen, im BLE seit heute morgen keine Änderung 23%.
Adapter bitte auf Loglevel debug stellen und einen Log-Auszug posten. Danach wieder zurück auf "info", sonst ist dein Log schnell voll.

chka

An bei die log
883_xiaomi_mi_pflanzensensor_.txt

AlCalzone

~~@chka:~~

nachtrag: in der flower care app habe ich einen bodenfeuchtigkeitswert von 45% nach dem giessen, im BLE seit heute morgen keine Änderung 23%. `
Direkt aus deinem Log => "got moisture update => 43"

Ich musste (wie https://forum.iobroker.net/viewtopic.php?p=136475#p136475 beschrieben) zwei der States umbenennen, da es von Xiaomi auch andere Sensoren gibt, die u.a. mit "humidity" die Luftfeuchtigkeit bezeichnen.

Humidity heißt jetzt Moisture und Brightness heißt jetzt Illuminance. Die alten States "Humidity" und "Brightness" kannst du löschen.

chka

super den Beitrag habe ich nicht gesehen nur das update gemacht :oops:

danke!

Meistertr

~~@apollon77:~~

@meistertr: also verstehe ich es korrekt das irgendwann der History Adapter die Daten nicht mehr loggt?

Um da tiefer reinzuschauen am besten mal debug im History aktivierten. (Im Notfall falls zu viele Datenpunkte da sind zweite History Instanz mit eigenem Verzeichnis anlegennund da auch aktivieren)

Mit Debug siehst du genau was passiert und was der Adapter entscheidet. Da ist dann die zeitliche Ecke relevant wenn er aufhört. Und bitte aktuellste Version. `

hab nun eine frische vm aufgesetzt mit debina9 node8 und dem neusten npm alle adapter auf latest und den neusten js-controller. Installiert ist nur ble und history. 2 Datenpunkte auf logging. hier die Ausgabe vom history debug:

history.0	2018-03-27 07:12:13.120	debug	Min-Delta reached ble.0.c4:7c:8d:65:c5:cd.rssi, last-value=-62, new-value=-63, ts=1522127533119
history.0	2018-03-27 07:12:02.123	debug	Min-Delta reached ble.0.c4:7c:8d:65:c5:cd.rssi, last-value=-63, new-value=-62, ts=1522127522123
history.0	2018-03-27 07:11:58.098	debug	Min-Delta reached ble.0.c4:7c:8d:65:c5:cd.temperature, last-value=25.9, new-value=25.3, ts=1522127518097
history.0	2018-03-27 07:11:52.117	debug	Min-Delta reached ble.0.c4:7c:8d:65:c5:cd.rssi, last-value=-65, new-value=-63, ts=1522127512117
history.0	2018-03-27 07:11:50.759	debug	system.adapter.admin.0: logging true
history.0	2018-03-27 07:11:48.035	debug	sendTo "getHistory" to system.adapter.admin.0 from system.adapter.history.0
history.0	2018-03-27 07:11:48.035	debug	Send: 2 values in: 1ms
history.0	2018-03-27 07:11:48.035	debug	after getFileData: cacheData.length = 2, fileData.length = 0
history.0	2018-03-27 07:11:48.035	debug	after getCachedData: length = 2, isFull=false
history.0	2018-03-27 07:11:48.034	debug	got 2 datapoints for ble.0.c4:7c:8d:65:c5:cd.temperature
history.0	2018-03-27 07:11:46.627	debug	system.adapter.admin.0: logging false
history.0	2018-03-27 07:11:44.693	debug	sendTo "getHistory" to system.adapter.admin.0 from system.adapter.history.0
history.0	2018-03-27 07:11:44.693	debug	Send: 2 values in: 0ms
history.0	2018-03-27 07:11:44.693	debug	after getFileData: cacheData.length = 2, fileData.length = 0
history.0	2018-03-27 07:11:44.693	debug	after getCachedData: length = 2, isFull=false
history.0	2018-03-27 07:11:44.693	debug	got 2 datapoints for ble.0.c4:7c:8d:65:c5:cd.temperature
history.0	2018-03-27 07:11:40.099	debug	Min-Delta reached ble.0.c4:7c:8d:65:c5:cd.rssi, last-value=-64, new-value=-65, ts=1522127500099
history.0	2018-03-27 07:11:39.418	debug	sendTo "getHistory" to system.adapter.admin.0 from system.adapter.history.0
history.0	2018-03-27 07:11:39.418	debug	Send: 2 values in: 0ms
history.0	2018-03-27 07:11:39.418	debug	after getFileData: cacheData.length = 2, fileData.length = 0
history.0	2018-03-27 07:11:39.418	debug	after getCachedData: length = 2, isFull=false
history.0	2018-03-27 07:11:39.418	debug	got 2 datapoints for ble.0.c4:7c:8d:65:c5:cd.temperature
history.0	2018-03-27 07:11:29.108	debug	Min-Delta reached ble.0.c4:7c:8d:65:c5:cd.rssi, last-value=-65, new-value=-64, ts=1522127489108
history.0	2018-03-27 07:11:18.115	debug	Min-Delta reached ble.0.c4:7c:8d:65:c5:cd.temperature, last-value=26.4, new-value=25.9, ts=1522127478115
history.0	2018-03-27 07:11:18.108	debug	Min-Delta reached ble.0.c4:7c:8d:65:c5:cd.rssi, last-value=-63, new-value=-65, ts=1522127478108

ich sehe da nix auffäliges aber in der Zeit sind die Einträge auf jeden fall wieder verschwunden

Arnulf

Ich habe 10 Pflanzensensoren im Einsatz. Keiner hält die History-Daten dauerhaft.

Aber ich habe noch eine andere Frage:

Ich habe einen von den Sensoren als chinesisches Modell erhalten.

Woher ich das weiß?

Die Fower-Care App hatte den Updateprozess abgebrochen. Danach war der Sensor nicht mehr zu finden (durch die App)

Jetzt habe ich mir für ein anderes Projekt (Fenstersensor) den Xiomi-Hub bestellt. Der muss, damit er funktioniert, auf China umgestellt werden.

Lustigerweise hat er den vermissten Sensor gefunden.

Aber eben NUR den vermissten Sensor. Die 9 yanderen nicht

Der ble-Adapter findet nur die internationale Variante der Sensoren. den chinesischen nicht.

Warum?

AlCalzone

~~@Arnulf:~~

Aber eben NUR den vermissten Sensor. Die 9 yanderen nicht

Der ble-Adapter findet nur die internationale Variante der Sensoren. den chinesischen nicht.

Warum? `
Ich sehe 2 Möglichkeiten:

1. Der chinesische Sensor sendet nicht auf der Charakteristik "fe95". Kannst du z.B. mit der App "nRF Connect" überprüfen, was der an Daten sendet:

2. Der Sensor ist nicht "initialisiert", d.h. der Adapter kann keine vollständigen Pakete dekodieren. Sollte sich anhand des Debug-Log herausfinden lassen.

Ich werde bei mir mal Dauer-Logging aktivieren und versuchen, ob ich das mit den verlorenen Daten nicht doch irgendwie nachvollziehen kann.

AlCalzone

Das nicht-Loggen war ein Bug im History-Adapter, der die Daten auf der Festplatte nicht wiedergefunden hat, weil die ":" in den IDs durch "~" ersetzt werden und das beim Lesen vergessen hat.

Wird in https://github.com/ioBroker/ioBroker.history/pull/23 gefixt.

Meistertr

~~@AlCalzone:~~

Das nicht-Loggen war ein Bug im History-Adapter, der die Daten auf der Festplatte nicht wiedergefunden hat, weil die ":" in den IDs durch "~" ersetzt werden und das beim Lesen vergessen hat.

Wird in https://github.com/ioBroker/ioBroker.history/pull/23 gefixt. ` Sehr cool super arbeit

Gesendet von meinem Handy

Malaus

Heute kamen drei weitere Sensoren an. Wollte die nun auch in ioBroker einbinden aber leider bekomme ich keine Werte.

Die Datenpunkte sind angelegt worden.

Der BLE Adapter hat die Version 0.5.2 und die Sensoren 2.7.0

Hatte von euch jemand schon mal das Problem?

Edit: Ich sehe gerade meine anderen zwei Sensoren haben die Version 3.1.8

Aber bei den neuen kommt überhaupt keine Meldung, dass es eine neuere Version gibt.

Arnulf

Ich habe gerade mal in Github in xiaomi_protocols.ts nachgeschaut und folgenden export gefunden:

export type XiaomiEventIDs =
	"temperature"
	| "humidity"
	| "illuminance"
	| "moisture"
	| "fertility"
	| "battery"
;

Da steht auch, dass "battery" ausgewertet werden sollte.

Nur leider wird das bei mir gar nicht in den Objekten angezeigt.

Mache ich hier was falsch?

ich habe aktuell 0.5.2 als BLE-Adapter installiert

AlCalzone

Das Xiaomi-Protokoll kann mehr als der Pflanzensensor sendet. Battery ist z.B. nur für den Temperatur/Feuchtigkeits-Sensor.

Machst also nix falsch, ich schätze den Batteriezustand muss man bei aktiver Verbindung auslesen (verbinden und steuern steht auf der TODO-Liste).

Arnulf

ah. Cool

Danke für die rasche Rückmeldung.

Ich habe (bishr noch vergeblich) versucht heraus zu finden, wie die Plugins aufgebaut sind.

Ich habe nämlich eine Waage, die der BLE-Adapter auch findet. Wäre lustig, wenn ich die auch auslesen könnte.

(Mal abgesehen davon, dass es noch eine Charge 2 gibt. Aber ich vermute, hier muss tatsächlich eine aktive Verbindung aufgebaut werden)

https://pewpewthespells.com/blog/fitbit_re.html

https://github.com/mrquincle/fitbit-fatbat

AlCalzone

~~@Arnulf:~~

Ich habe (bishr noch vergeblich) versucht heraus zu finden, wie die Plugins aufgebaut sind.

Ich habe nämlich eine Waage, die der BLE-Adapter auch findet. Wäre lustig, wenn ich die auch auslesen könnte. `

Das muss ich mal besser dokumentieren. Eine Erklärung findet sich zum Teil hier: https://github.com/AlCalzone/ioBroker.b … /plugin.ts

Die Plugin-Module exportieren ein Objekt vom Typ Plugin mit folgenden Eigenschaften:

name: Name des Plugins (wird im Konfig-Dialog eingegeben)
description: Beschreibung des Plugins (aktuell nicht verwendet, wird in Zukunft im Konfig-Dialog angezeigt)
advertisedServices: String-Array der Services, auf die gelauscht werden soll
isHandling: Funktion, die ein https://github.com/AlCalzone/ioBroker.ble/blob/master/src/lib/ble.d.ts übergeben bekommt und anhand dessen prüft, ob das Plugin überhaupt zuständig ist. Im einfachsten Fall geht das nach der Mac-Adresse (Xiaomi), andernfalls muss man z.B. prüfen, ob das Plugin mit den Daten was anfangen kann (ruuvi-tag).
createContext: Funktion, die ebenfalls ein BLE peripheral übergeben bekommt (nur wenn das Plugin zuständig ist). Der Rückgabewert wird 1:1 an die nächsten Funktionen übergeben, hier sollte also die Auswertung der empfangenen Daten stattfinden.

defineObjects: Funktion, die den eben erstellten Kontext erhält und zurückgibt, welche Objekte in der Struktur erstellt werden sollen. Siehe https://github.com/AlCalzone/ioBroker.b … gin.ts#L11

interface PeripheralObjectStructure {
	/**
	 * How the device object should look like.
	 * May be null if the plugin knows that the object exists.
	 */
	device: DeviceObjectDefinition;
	/**
	 * Which channels to create.
	 * May be null if the plugin knows that the objects exist or none should be created.
	 */
	channels: ChannelObjectDefinition[];
	/**
	 * Which states to create.
	 * May be null if the plugin knows that the objects exist.
	 */
	states: StateObjectDefinition[];
}

Die xyzObjectDefinitions sind wiederum Objekte, die common und native der ioBroker-Objekte enthalten - für channel und state auch die ID. Z.B.: für einen State:

{
	id: "temperature",
	common: {
		role: "value",
		name: "Temperature",
		type: "number",
		unit: "°C",
		read: true,
		write: false,
	},
	native: null,
}

Es müssen nicht immer alle State-Objekte enthalten sein, z.B. wenn das Gerät die Advertisements rotiert.

getValues: Funktion, die ebenfalls den Kontext erhält und eine Auflistung der Werte zurück gibt, die in ioBroker gesetzt werden sollen. Wobei der Key gleich der ID des State-Objekts entspricht. Z.B.:
```
{
  temperature: 19.7, // für ble.0.aa:bb:cc:dd:ee:ff.<deviceid>.<channelid>.temperature
  humidity: 50.7
}</channelid></deviceid>
```

Meistertr

Kurze Rückmeldung meinerseits, die daten werden nun nach dem history update alle ordentlich geloggt, danke nochmal..

Arnulf

hilfe…

Ich bekomme seit gestern unmengen an Geräten in die Liste

(und das sind nur ein paar von ca. 80)

Vom RSSI-Signal (-55) müssten die alle um mi9ch gerum sein.

Das kann doch aber gar nicht sein

Beispielhaft mal Raw-Daten von einem "Fang"
5197_2018-04-05_17_11_16-iobroker.admin.png

Hier die Einstellung des Adapters:
5197_2018-04-05_17_14_26-iobroker.admin.png

Hat jemand eine Idee, warum das sein kann?

Die MAC-Adressen kann ich gar nicht zuordnen. Auch nicht aus Quellen im Internet

Community Forum

NEWS

Xiaomi Mi Pflanzensensor

Support us

790

32.5k

81.6k

1.3m