LAN-Anbindung für BSB-Bus (Brötje, Elco Thision etc.)

[freetz]

Das Definement ist wie gesagt in der Datei PubSubClient.h, nicht in der BSB_lan_config.h. Aber wie gesagt, wenn man es komplett neu installiert, wird auch die Datei entsprechend überschrieben, so dass es passen sollte.

[FunkOdyssey]

Und ich habe gerade noch mal mit dem User gesprochen, der die Änderung programmiert hat: Dazu musste in der Datei /src/PubSubClient/PubSubClient.h die Zeile
#define MQTT_MAX_PACKET_SIZE
auf 1024 geändert werden. Das ist bei meinem Master-Repository auch der Fall. Kann es aber sein, dass Du dieses Unterverzeichnis vielleicht nicht aktualisiert hast? Wenn da nur 128 steht, ist das jedenfalls der Grund, warum nichts ankommt, weil der Buffer für den langen JSON-String zu klein ist.

Die Datei liegt in /src/PubSubClient/src/PubSubClient.h und war bei mir korrekt.
Im SerialMonitor konnte ich aber erkennen, dass mein JSON sehr lang war. 1900 Zeichen.
Da du mich ja quasi mit der Nase darauf gestoßen hast, habe ich MQTT_MAX_PACKET_SIZE auf 2048 gesetzt und nach nur wenigen Minuten hatte ich meine Daten im MQTT2_DEVICE in FHEM.

Ich frage einfach zu viele Werte und zu lange Strings ab. Schade, dass alles in einem JSON übermittelt wird.
Bei EBUSD werden die Werte einzeln in JSONs übertragen.

Meine weitere große Hoffnung auf Mehrwert hat sich aber auch zerschlagen. Mir fehlt die Uhrzeit bei den Fehlern. Im BSB-Web werden Datum/Uhrzeit angezeigt. Über MQTT kommt aber nur das Datum.

Auch sehe ich hier im JSON keine Vorteile, da hier keine multidimensionalen Arrays übertragen werden.
Ich sehe nur "ParameterID":"Wert".

Aber danke dir für deine Hilfe. Wieder einmal.

[freetz]

Das mit der Uhrzeit kann ich noch mal schauen, mach' dazu bitte ein Issue auf GitHub auf mit genauer Beschreibung. Und was meinst Du mit mehrdimensionalen Arrays?

[FunkOdyssey]

Und was meinst Du mit mehrdimensionalen Arrays?

Ich habe das einfach mal so genannt. 
Ich befürchte, dass ich bei BSB kein passenden Beispiel finde, da jeder Parameter eindeutig ist und nur einen Wert beinhaltet.
Bei anderen MQTT2-Geräten habe ich in einem JSON-Array, den aktuelle Wert, den Standardwert, etc.
Das trifft hier aber alles nicht zu. Darum verstehe ich das Define MQTT_JSON auch nicht richtig. IN FHEM war das doppelter Aufwand. Parameter in JSON => übertragen => per jsonMap wieder auseinandernehmen.

Man könnte das JSON natürlich um die Parameterbezeichnung erweitern. Oder Fehlercode vom Text trennen. Oder Datum und Uhrzeit trennen. Das hätte Charme.

Beispiel:

Aktuell:

Code Auswählen Erweitern

{"BSB-LAN":{"status":{"700":"1 - Automatik","6801":"110 - Sicherheitstemperaturbegrenzung Störabschaltung",}}

Besser:

Code Auswählen Erweitern

{"BSB-LAN":{"status":{"700":"Betriebsart":"1":"Automatik","6801":"Historie02_DatumZeit":"110":"Sicherheitstemperaturbegrenzung Störabschaltung",}}

Wäre aber sicherlich enormer Aufwand für dich. Und auf der Seite der Anwender nimmt man sowieso alles nur einmal in Betrieb und muss danach selten etwas ändern.

[freetz]

Hier die Antwort des Users zu Deinen Fragen/Thesen:

The size limit imposed by PubSubClient is arbitrary and simply to try and limit the impact on memory for smaller devices I think. MQTT in general is designed to handle massive payloads, with the specification allowing a 65535 character max for the topic and a 256Mb max size for a single payload, so a user changing the size in the .h file is not a problem as long as they have the memory to handle the array size.

The power of json on the other hand lies in the fact that you can send a whole lot of unrelated key:value pairs in a single payload and then easily extract them at the destination. Breaking the payload up into individual json "posts" would be going against the principle reason for using json to package the data, and one would be better off just using the standard mqtt option where the values are posted individually one at a time. Where I encounter systems that only allow the raw data to be posted, I use something like Node-Red to collect this data and build it into a json structure for ease of use.

Regarding the use of arrays. It would be interesting to know what the user is dumping to mqtt. Arrays are very useful in json structures as they can be used to group common elements together under a single heading in the json structure and this makes extracting the values later much easier. But, this assumes that you have some form of hierarchical structure for the data you are posting.

For BSB you are really just outputting individual values at this point. I have the feeling that the user is thinking of the data in terms of the web page structure, and would like the json to be build to match that. So, for instance, one would have an output that looked something like the below, where each sub section of the web page would be an array in the json.

{
"heaterFunctions": [
   {
     "0-dateTime": [
       {
         "0": "val1",
         "1": "val2",
         "2": "val3",
         "3": "val4",
         "5": "val5",
         "6": "val6"
       }
     ]
   },
   {
     "1-roomUnit": [
       {
         "20": "val1",
         "22": "val2",
         "23": "val3",
         "25": "val4",
         "26": "val5",
         "27": "val6",
         "etc..": "val..etc"
       }
     ]
   },
   {
     "2-wireless": [
       {
         "etc..": "val..etc"
       }
     ]
   }
]
}

While this could be nice, I don't think it's appropriate for BSB. One would only really consider this approach if all interactions were done via mqtt and not http. A great option if the application was purely machine to machine, but not appropriate for this use case (in my humble opinion) where human interaction is the primary interface.

Besides, you provide all the data needed for somebody to build the above structure using some external program if they wanted. Native java could do this, or Node-Red as mentioned before. I use this approach for IoT systems often, as you want as little hard coded data structures in the sensor devices as possible. The reason being that if you want to change something, it's always easier to change a single central bit of code, then lots of edge devices.

[iTob]

Hi,
ich habe durch das Handbuch hier im Thread die Lösung für das frozen-lan-shield Problem gefunden. Leider finde ich aber einfach nicht die Beschreibung, wie es sich genau äußert. 
Ich habe seit ein paar Tagen das Problem, dass der Adapter gelegentlich einfriert. Er ist über die Web-Oberfläche nicht erreichbar, sendet auch keine MQTT Meldungen mehr. Intressanter Weise reagiert er noch auf den Ping. Einmal ab- und anstecken und alles ist wieder OK.
Könnte da die Lösng zum frozen-lan-shield Problem helfen?
Viele Grüße
Tobias

[frank]

ich habe für mein clone-shield bisher keine dauerhafte lösung gefunden. daher habe ich irgend wann aufgegeben und wieder mein problemloses original-shield genommen.

alle beschreibungen klingen ähnlich, äussern sich im detail aber auch unterschiedlich. daher gibt es auch viele lösungsvorschläge. bei keiner variante habe ich gelesen, dass sie allen geholfen hat.

probiere alles aus, was du findest.

[postman]

Moin zusammen,
iTob, bei mir war es genau der von Dir beschriebene Fehler; es funktioniert eine gewisse Zeit (teilweise sogar mehrere Wochen) und setzt dann einfach, wie von Dir beschrieben, aus. Ich betreile den Arduino direkt an einem Raspberry, auf dem neben dem FHEM auf ein RDP läuft. Ich habe dort eine Arduione IDE installiert, so dass ich dort auch den SerMon aufrufen kann. Wenn ich es richtig verstanden habe, wird mit dem Aufruf der Arduino resettet. Danach funktionierte es wieder, bis zum nächsten Mal. Ich habe nun die Version 0.42, Stand 25.10.2019, installiert. Diese läuft bei mir ohne Probleme (Auch ohne regelmäßiges Starten des SerMon). Änderungen an der Hardware habe ich nicht vorgenommen.
Ansonsten; einfach mal freetz fragen, der weiss vielleicht noch eine Lösung 
Gruß
Uwe

[freetz]

Ich habe das Problem nicht, deswegen kann ich da nicht helfen, aber vielleicht wäre dafür ein eigener Thread hilfreich, auf den man verweisen könnte, denn wenn ich mich richtig erinnere, ist das ja kein BSB-LAN-spezifisches Problem und dann könnte man Neulinge mit dem Problem darauf verweisen.
Einer von Euch hatte doch mal ein sehr gute Analyse dazu geschrieben, das könnte ja ein guter Einstiegs-Post sein, und dann könnten die anderen ihre jeweiligen Lösungen oder Workarounds da posten, denn wie Frank geschrieben hat: es gibt keine Lösung, die bei allen funktioniert (außer ein original Shield kaufen)...

[FunkOdyssey]

Hier die Antwort des Users zu Deinen Fragen/Thesen:

Danke. Ja, wir reden über das Gleiche.

For BSB you are really just outputting individual values at this point.

Ja, das ist der Grund wieso wir eigentlich nicht weiterreden müssen. BSB liefert flache und individuelle Daten. Man kann die Parameter schlecht in ein komplexes JSON packen. Das was jetzt herauskommt, ist super - aber die neue JSON-Funktionalität bringt uns in FHEM keine Vorteile. Aber ich bin auch kein MQTT-Profi.
Du hast alles super gemacht und den Contributor hat ein weiteres nettes Gimmick hinzugesteuert. Danke.

I have the feeling that the user is thinking of the data in terms of the web page structure, and would like the json to be build to match that. So, for instance, one would have an output that looked something like the below, where each sub section of the web page would be an array in the json.

Das wäre zu komplex. Zum Beispiel eine ganze Kategorie in ein Payload packen, wäre der Overkill.

Ein wenig schade ist es, dass man die MQTT-Parameter in der Config angeben muss. Man ist nicht so flexibel wie über HTTPMOD. Man muss halt jedesmal neu flashen. Aber wie oft kommt das vor.

Danke für deine Arbeit.

[freetz]

Nur kurz, da ich gerade mit einer Mittelohrentzündung flach liege: Die MQTT Parameter sind die gleichen wie die Log-Parameter, und die kann man zur Laufzeit über /L setzen.

[FunkOdyssey]

Genial. Danke schön und eine gute Besserung.

[iTob]

Dankeschön für die Infos. Momentan läuft mein Adapter wieder stabil.
Die Idee mit dem extra Thread finde ich gut. Die 300 Seiten sind wirklich unübersichtlich. 

Einmal hatte ich das Problem, dass er über http nicht mehr erreichbar war, hat aber noch per mqtt gesendet. Seltsam... Aber ein Neustart hat geholfen.
VG

[fabulous]

Moin,

ich gehöre seit heute ebenfalls zu den Nutzern des Adapters.
@freetz: vielen Dank für die Platine und die Bauteile.

Derzeit läuft der Adapter testweise an einem alleinstehenden RVS43.325. Scheint auch zu funktionieren; Werte werden im Webinterface angezeigt.

Final soll er an einer Brötje L-UB 17C (mit RVS43.122) seinen Dienst verrichten.
Sobald ich umgebaut habe, kann ich Werte bereitstellen.

Vielen Dank für die Arbeit die Ihr da investiert habt.

Gruß
Fabian

[fabulous]

Moin,

hab umgebaut.

Der Adapter läuft jetzt an einer Brötje L-UB 17C Ölheizung mit RVS43.122.
Es sind ausserdem zwei RGT angeschlossen sowie ein EWM.

/6220-6236 liefert:

Code Auswählen Erweitern


6220 Konfiguration - Software-Version: 1.4
6222 Konfiguration - Gerätebetriebsstunden: 63055 h
6223 Konfiguration - Bisher unbekannte Geräteabfrage: 20
6224 Konfiguration - Geräte-Identifikation: RVS43.122/100
6225 Konfiguration - Gerätefamilie: 95
6226 Konfiguration - Gerätevariante: 100
6227 Konfiguration - Objektverzeichnis-Version: 1.0
6229 Konfiguration - EEPROM-Version: ---
6236 Konfiguration - Hersteller-ID (letzten vier Bytes): 68874


/Q liefert:

Code Auswählen Erweitern


Version: 0.44.9-20200402070901
Scanne nach Geräten...
Geräteadresse gefunden: 0
Geräteadresse gefunden: 3
Geräteadresse gefunden: 7
Geräteadresse gefunden: 10

Teste Geräteadresse 0:
Gerätefamilie: 95
Gerätevariante: 100
Geräte-Identifikation: RVS43.122/100
Software-Version: 1.4
Entwicklungs-Index:
Objektverzeichnis-Version: 1.0
Bootloader-Version:
EEPROM-Version: 50.0
Konfiguration - Info 2 OEM:
Zugangscode Inbetriebnahme?:
Zugangscode Fachmannebene ?:
Zugangscode OEM?:
Zugangscode OEM2?:
Bisher unbekannte Geräteabfrage: 20
Hersteller-ID (letzten vier Bytes): 68874
Bisher unbekannte Geräteabfrage: 00010001F4 - unknown type
Außentemperatur (10003): 15.4 °C
Außentemperatur (10004): 15.4 °C

6225;6226;6224;6220;6221;6227;6229;6231;6232;6233;6234;6235;6223;6236;6237;
95;100;RVS43.122/100;1.4;;1.0;50.0;;;;;;20;68874;00010001F4 - unknown type;


Starte Test...

5024
5024 Trinkwasserspeicher - TWW Schaltdifferenz 1 ein: error 7 (parameter not supported)
DC C2 00 0B 06 3D 31 07 1D 31 A4
DC 80 42 0E 07 31 3D 07 1D 00 01 40 79 BB
5951
5951 Konfiguration - Wirksinn Kontakt H1: error 7 (parameter not supported)
DC C2 00 0B 06 3D 05 04 87 5F 61
DC 80 42 0D 07 05 3D 04 87 00 01 53 AE
5960
5960 Konfiguration - Funktion Eingang H3: error 7 (parameter not supported)
DC C2 00 0B 06 3D 05 04 84 6F 02
DC 80 42 0D 07 05 3D 04 84 00 02 3A 9D
5961
5961 Konfiguration - Wirksinn Kontakt H3: error 7 (parameter not supported)
DC C2 00 0B 06 3D 05 05 75 A3 0D
DC 80 42 0D 07 05 3D 05 75 00 01 A8 28
6801
6801 Fehler - Historie 1 Fehlercode: error 7 (parameter not supported)
DC C2 00 0B 06 3D 05 06 DD C2 BC
DC 80 42 0D 07 05 3D 06 DD 00 62 7B 0C
6803
6803 Fehler - Historie 2 Fehlercode: error 7 (parameter not supported)
DC C2 00 0B 06 3D 05 06 DE F2 DF
DC 80 42 0D 07 05 3D 06 DE 00 62 22 5C
6811
6811 Fehler - Historie 6 Fehlercode: error 7 (parameter not supported)
DC C2 00 0B 06 3D 05 06 E2 05 00
DC 80 42 0D 07 05 3D 06 E2 00 62 92 98
6811
6811 Fehler - Historie 6 Fehlercode: error 7 (parameter not supported)
DC C2 00 0B 06 3D 05 06 DE F2 DF
DC 80 42 0D 07 05 3D 06 DE 00 62 22 5C
6813
6813 Fehler - Historie 7 Fehlercode: error 7 (parameter not supported)
DC C2 00 0B 06 3D 05 06 E3 15 21
DC 80 42 0D 07 05 3D 06 E3 00 83 48 A7
6815
6815 Fehler - Historie 8 Fehlercode: error 7 (parameter not supported)
DC C2 00 0B 06 3D 05 06 E4 65 C6
DC 80 42 0D 07 05 3D 06 E4 00 83 CD 37
6817
6817 Fehler - Historie 9 Fehlercode: error 7 (parameter not supported)
DC C2 00 0B 06 3D 05 06 E5 75 E7
DC 80 42 0D 07 05 3D 06 E5 00 83 FA 07
6819
6819 Fehler - Historie 10 Fehlercode: error 7 (parameter not supported)
DC C2 00 0B 06 3D 05 06 E6 45 84
DC 80 42 0D 07 05 3D 06 E6 00 62 4E 58
7042
7042 Wartung/Sonderbetrieb - Brennerstarts Intervall: error 7 (parameter not supported)
DC C2 00 0B 06 3D 05 05 DF B7 AD
DC 80 42 0E 07 05 3D 05 DF 01 23 28 41 A5
7840
7840 Ein-/Ausgangstest - Spannungssignal H1: error 7 (parameter not supported)
DC C2 00 0B 06 3D 05 05 79 62 81
DC 80 42 0D 07 05 3D 05 79 00 00 CD 68
7841
7841 Ein-/Ausgangstest - Kontaktzustand H1: error 7 (parameter not supported)
DC C2 00 0B 06 3D 05 04 5D 35 56
DC 80 42 0D 07 05 3D 04 5D 00 00 E1 DA
8323
8323 Diagnose Erzeuger - Gebläsedrehzahl: error 7 (parameter not supported)
DC C2 00 0B 06 05 21 05 18 ED 2A
DC 80 42 0E 07 21 05 05 18 01 00 00 D8 0D
9000
9000 Diagnose Verbraucher - Vorlaufsollwert H1: error 7 (parameter not supported)
DC C2 00 0B 06 3D 05 05 76 93 6E
DC 80 42 0E 07 05 3D 05 76 01 01 40 D5 8E Test beendet.

Teste Geräteadresse 3:
Gerätefamilie: 91
Gerätevariante: 100
Geräte-Identifikation: AVS75.390/100
Software-Version: 2.1
Entwicklungs-Index:
Objektverzeichnis-Version: 1.0
Bootloader-Version:
EEPROM-Version:
Konfiguration - Info 2 OEM:
Zugangscode Inbetriebnahme?:
Zugangscode Fachmannebene ?:
Zugangscode OEM?:
Zugangscode OEM2?:
Bisher unbekannte Geräteabfrage: 20
Hersteller-ID (letzten vier Bytes): 21730
Bisher unbekannte Geräteabfrage:
Außentemperatur (10003):
Außentemperatur (10004):

6225;6226;6224;6220;6221;6227;6229;6231;6232;6233;6234;6235;6223;6236;6237;
91;100;AVS75.390/100;2.1;;1.0;;;;;;;20;21730;;


Starte Test...
Test beendet.

Teste Geräteadresse 7:
Gerätefamilie: 94
Gerätevariante: 100
Geräte-Identifikation: QAA75.611/100
Software-Version: 7.6
Entwicklungs-Index:
Objektverzeichnis-Version: 102.0
Bootloader-Version:
EEPROM-Version:
Konfiguration - Info 2 OEM:
Zugangscode Inbetriebnahme?:
Zugangscode Fachmannebene ?:
Zugangscode OEM?:
Zugangscode OEM2?:
Bisher unbekannte Geräteabfrage: ---
Hersteller-ID (letzten vier Bytes): 572725
Bisher unbekannte Geräteabfrage:
Außentemperatur (10003):
Außentemperatur (10004):

6225;6226;6224;6220;6221;6227;6229;6231;6232;6233;6234;6235;6223;6236;6237;
94;100;QAA75.611/100;7.6;;102.0;;;;;;;---;572725;;


Starte Test...
Test beendet.

Teste Geräteadresse 10:
Gerätefamilie: 92
Gerätevariante: 100
Geräte-Identifikation: AVS37.294/100
Software-Version: 5.3
Entwicklungs-Index:
Objektverzeichnis-Version: 102.0
Bootloader-Version:
EEPROM-Version:
Konfiguration - Info 2 OEM:
Zugangscode Inbetriebnahme?:
Zugangscode Fachmannebene ?:
Zugangscode OEM?:
Zugangscode OEM2?:
Bisher unbekannte Geräteabfrage: ---
Hersteller-ID (letzten vier Bytes): 476693
Bisher unbekannte Geräteabfrage:
Außentemperatur (10003):
Außentemperatur (10004):

6225;6226;6224;6220;6221;6227;6229;6231;6232;6233;6234;6235;6223;6236;6237;
92;100;AVS37.294/100;5.3;;102.0;;;;;;;---;476693;;


Starte Test...
Test beendet.

Fertig.


Gruß
Fabian