@rene55
Warte noch ein paar Minuten. Da kommt noch mehr..
Ja, ich hab auch BMI 600.
Mach mal Deinen Chat für mich auf. Da tauschen wir ein paar pers. Daten aus um besser zu kommunizieren...
@rene55
Warte noch ein paar Minuten. Da kommt noch mehr..
Ja, ich hab auch BMI 600.
Mach mal Deinen Chat für mich auf. Da tauschen wir ein paar pers. Daten aus um besser zu kommunizieren...
@rene55
Stimmt, die Fehlermeldung bekomme ich auch, wenn ich meinen eigenen Flow importieren will. Sorry, da muss beim Export etwas schief gegangen sein.
Versuche es bitte damit nochmal:
msg.payload
it is necessary to specify a msg.top
properity in addition to the msg-Object.\n\nThe object tree will be created under 0_userdata.0\n\nExisting msg.topic
entries will be deleted.\nAn iobroker-out node has to be appended to this subflow node. It is not part of the subflow itself. No topic should be specified in the iobroker out node.\n\nIs msg.top
property isn't defined, the top
property of the subflow-node is used. \n\nIn the properties of the subflow node a new property keepTopic
has been added. Default is false to keep the current behaviour. If set to true then the originial topic will be placed between the top
property of the subflow node and the property of the analyzed JSON object.\n\nAttention:\nIf msg.top and top is empty, all msg.topics (msg.topic) will be directly prefixed with 0_userdata.0. . \n\nUpdate 13.09.2022:\nSpaces in topics of objects are no longer replaced with underscores in objects. No differences between all data types.\n\n# Erstellt einen Objektbaum im ioBroker\n\nDiese Node erstellt einen Objektbaum im ioBroker aus einem JAVA Objekt bzw. einem JSON String. \n\nDer Baum wird in jedem Fall unter 0_userdata.0 erstellt und zwar unter dem Topic der in msg.top
mitgegeben wurde. In der msg.payload
befindet sich dann der JSON String oder das entsprechende Objekt.\n\nExistierende msg.topic
Einträge werden gelöscht.\nEin entsprechende iobroker-out Node muss an den Flow angehängt werden. Sie ist nicht Bestandteil des Subflows. In dieser iobroker-out Node darf kein Topic angegeben werden. \n\nFalls msg.top nicht definiert wurde, wird der top
-Wert der Subflow-Node verwendet.\n\nIn den Eigenschaften der Subflow-Node wurde ein neuer Parameter keepTopic
hinzugefügt. Standardwert ist false, um das bisherige Verhalten beizubehalten. Setzt man die Eigenschaft auf true, dann wird das originale Topic zwischen der top
Eigenschaft der Subflow-Node und Eigenschaft des analysierten JSON Objektes eingefügt.\n\nAchtung:\nWenn top und msg.top leer ist, werden alle msg.topics (msg.topic) direkt unter dem Präfix 0_userdata.0., angelegt bzw. ausgegeben. \n\nUpdate 13.09.2022:\nLeerzeichen werden in Topics von Objekten nicht mehr durch Unterstriche ersetzt. Es gibt keine Unterschiede mehr zwischen den Datentypen.",10000
\r\n\r\nDefault host IP: \r\n47.88.8.200
(data1.solarmanpv.com
) \r\nor \r\n115.29.186.234
(data2.solarmanpv.com
) \r\n\r\nDefault port nr: \r\n10000
\r\n\r\n### References\r\n\r\n - GitHub - the node github repository\r\n",req code: 0x${requestTypeByte.toString(16)}
);\n let responseTypeByte = requestTypeByte - (0x30);\n responseTypeByte = Math.min(Math.max(responseTypeByte, 0x00), 0xFF); //min 0x00 max 255\n // switch(requestTypeByte) {\n // case 0x41:\n // responseTypeByte = 0x11;\n // break;\n // case 0x42:\n // responseTypeByte = 0x12;\n // break;\n // case 0x43:\n // responseTypeByte = 0x13;\n // break;\n // case 0x47:\n // responseTypeByte = 0x17;\n // break;\n // case 0x48:\n // responseTypeByte = 0x18;\n // break;\n // default:\n // responseTypeByte = 0xFF;\n // }\n // node.warn(res code: 0x${responseTypeByte.toString(16)}
);\n return responseTypeByte;\n}\nfunction calculateChecksum(message) {\n message = message.slice(1, -2);\n let sum = 0x0;\n for (const key of message.keys()) {\n sum += message[key];\n }\n sum = sum % 256;\n // node.warn( sum.toString(16));\n return sum;\n}",${
0${(buff.toString(16))}.slice(-2)}:
;\n }\n return macAddressStr.substring(0, 17);\n}\nfunction readSensorTypeList(buffer) {\n let SensorTypeListStr = ${
0${(buffer[1].toString(16))}.slice(-2)}
;\n SensorTypeListStr += ${
0${(buffer[0].toString(16))}.slice(-2)}
;\n return SensorTypeListStr;\n}\n\nfunction decodeInverterStatus(status) {\n switch (status) {\n case 0x00:\n return standby
;\n case 0x02:\n return normal
;\n case 0x03:\n return fault
;\n case 0x04:\n return permanent
;\n default:\n return 0x${
0${(status.toString(16))}.slice(-2)}
;\n }\n}\n",data(${msg.payload.length})
;\n break;\n case 14:\n frameType = 'heartbeat(14)';\n break;\n case 41:\n frameType = 'hello_cd(41)';\n break;\n case 73:\n frameType = 'hello_end(73)';\n break;\n default:\n frameType = unknown(${msg.payload.length})
;\n break;\n}\nmsg.frameType = frameType;\n// delete TCP nodes properties\ndelete msg.ip;\ndelete msg.host;\ndelete msg.port;\ndelete msg._session;\n\nreturn msg;",@rene55
Diese Pakete kommen schon mal vom Bosswerk, da alle Pakete im Data 5 Protokoll mit 165 beginnen. Messages mit einer Länge von 143 sind mir allerdings unbekannt.
Mindest die Heartbeat-Msg mit der Länge von 14 sollte alle 5 Minuten ankommen.
Hast Du im config_hide Menü Server A auf deinen node-red umgebogen ? Beim optionalen Server kommt zumindestens bei mir nix an.
Ist der tcp Input-node im Ausgang auf "Strom von" "Buffer" gestellt ?
Nimm meinen Flow, da sparst Du ne Menge Zeit und kannst bei der weiteren Decodierung helfen. Im Flow selbst kannst Du das forwarding der Nachrichten zum Solarman Server ein/ausschalten. Damit funktioniert dann auch noch die Solarman App.
Gerne. Voraussetzung - node red adapter.
Du musst in den Node-Red Einstellungen "Erstellung von Fremdobjekten zulassen" aktivieren, damit die Datenpunkte erstellt werden.
Alle bosswerk relevanten pv Daten sind in der 547-msg length drin. Screen mal die 60ér und 73ér msg. Da wird Deine ip und Wifi Adresse übertragen...
msg.payload
it is necessary to specify a msg.top
properity in addition to the msg-Object.\n\nThe object tree will be created under 0_userdata.0\n\nExisting msg.topic
entries will be deleted.\nAn iobroker-out node has to be appended to this subflow node. It is not part of the subflow itself. No topic should be specified in the iobroker out node.\n\nIs msg.top
property isn't defined, the top
property of the subflow-node is used. \n\nIn the properties of the subflow node a new property keepTopic
has been added. Default is false to keep the current behaviour. If set to true then the originial topic will be placed between the top
property of the subflow node and the property of the analyzed JSON object.\n\nAttention:\nIf msg.top and top is empty, all msg.topics (msg.topic) will be directly prefixed with 0_userdata.0. . \n\nUpdate 13.09.2022:\nSpaces in topics of objects are no longer replaced with underscores in objects. No differences between all data types.\n\n# Erstellt einen Objektbaum im ioBroker\n\nDiese Node erstellt einen Objektbaum im ioBroker aus einem JAVA Objekt bzw. einem JSON String. \n\nDer Baum wird in jedem Fall unter 0_userdata.0 erstellt und zwar unter dem Topic der in msg.top
mitgegeben wurde. In der msg.payload
befindet sich dann der JSON String oder das entsprechende Objekt.\n\nExistierende msg.topic
Einträge werden gelöscht.\nEin entsprechende iobroker-out Node muss an den Flow angehängt werden. Sie ist nicht Bestandteil des Subflows. In dieser iobroker-out Node darf kein Topic angegeben werden. \n\nFalls msg.top nicht definiert wurde, wird der top
-Wert der Subflow-Node verwendet.\n\nIn den Eigenschaften der Subflow-Node wurde ein neuer Parameter keepTopic
hinzugefügt. Standardwert ist false, um das bisherige Verhalten beizubehalten. Setzt man die Eigenschaft auf true, dann wird das originale Topic zwischen der top
Eigenschaft der Subflow-Node und Eigenschaft des analysierten JSON Objektes eingefügt.\n\nAchtung:\nWenn top und msg.top leer ist, werden alle msg.topics (msg.topic) direkt unter dem Präfix 0_userdata.0., angelegt bzw. ausgegeben. \n\nUpdate 13.09.2022:\nLeerzeichen werden in Topics von Objekten nicht mehr durch Unterstriche ersetzt. Es gibt keine Unterschiede mehr zwischen den Datentypen.",10000
\r\n\r\nDefault host IP: \r\n47.88.8.200
(data1.solarmanpv.com
) \r\nor \r\n115.29.186.234
(data2.solarmanpv.com
) \r\n\r\nDefault port nr: \r\n10000
\r\n\r\n### References\r\n\r\n - GitHub - the node github repository\r\n",req code: 0x${requestTypeByte.toString(16)}
);\n let responseTypeByte = requestTypeByte - (0x30);\n responseTypeByte = Math.min(Math.max(responseTypeByte, 0x00), 0xFF); //min 0x00 max 255\n // switch(requestTypeByte) {\n // case 0x41:\n // responseTypeByte = 0x11;\n // break;\n // case 0x42:\n // responseTypeByte = 0x12;\n // break;\n // case 0x43:\n // responseTypeByte = 0x13;\n // break;\n // case 0x47:\n // responseTypeByte = 0x17;\n // break;\n // case 0x48:\n // responseTypeByte = 0x18;\n // break;\n // default:\n // responseTypeByte = 0xFF;\n // }\n // node.warn(res code: 0x${responseTypeByte.toString(16)}
);\n return responseTypeByte;\n}\nfunction calculateChecksum(message) {\n message = message.slice(1, -2);\n let sum = 0x0;\n for (const key of message.keys()) {\n sum += message[key];\n }\n sum = sum % 256;\n // node.warn( sum.toString(16));\n return sum;\n}",${
0${(buff.toString(16))}.slice(-2)}:
;\n }\n return macAddressStr.substring(0, 17);\n}\nfunction readSensorTypeList(buffer) {\n let SensorTypeListStr = ${
0${(buffer[1].toString(16))}.slice(-2)}
;\n SensorTypeListStr += ${
0${(buffer[0].toString(16))}.slice(-2)}
;\n return SensorTypeListStr;\n}\n\nfunction decodeInverterStatus(status) {\n switch (status) {\n case 0x00:\n return standby
;\n case 0x02:\n return normal
;\n case 0x03:\n return fault
;\n case 0x04:\n return permanent
;\n default:\n return 0x${
0${(status.toString(16))}.slice(-2)}
;\n }\n}\n",data(${msg.payload.length})
;\n break;\n case 14:\n frameType = 'heartbeat(14)';\n break;\n case 41:\n frameType = 'hello_cd(41)';\n break;\n case 73:\n frameType = 'hello_end(73)';\n break;\n default:\n frameType = unknown(${msg.payload.length})
;\n break;\n}\nmsg.frameType = frameType;\n// delete TCP nodes properties\ndelete msg.ip;\ndelete msg.host;\ndelete msg.port;\ndelete msg._session;\n\nreturn msg;",@sborg
Hallo, das ist ein interessanter Ansatz aber unnötig: Du kannst die Bosswerk Solarman Server -Adresse direkt im Inverter über ein verstecktes Menü ändern:
http://<lokale IP des Bosswerk Inverters>/config_hide.html
Hier habe ich dann die IP-Adresse auf einen eigenen Node-red input verbogen und dann damit die eingehenden Datenpakete analysiert. Ich kann zwar (noch) nicht alles entschlüsseln, komme aber an alle relevanten PV Daten ran und habe daraus eigene Datenpunkte gezogen.
Dabei kam die große Überraschung: Die Bosswerk Inverter und damit alle baugleichen Geräte übertragen die eigene lokale IP-Adresse und die WIFI SSID an die Solarman-Server. Ob auch das WIFI Password dabei ist, kann ich nicht sagen, da ich nicht alles dechiffriert bekomme. Aber die Vermutung liegt nahe..
Ich habe jetzt jedenfalls die komplette Kommunikation an die Solarman-Server unterbrochen. Das ist mir zu unheimlich...
Im Klartext heißt das, dass alle die die SOLARMAN-App nutzen und ihre Inverter entsprechend eingerichtet haben, gleichzeitig auch sensible Daten weiterleiten. Und wenn man dann auch noch seine GEO-Daten in der App eingibt... Na Ihr könnt es Euch denken.
Hi,
ja, damit funktioniert es. Dann aber mit Cloud und Skill, was ich eigentlich nicht möchte. Keine Flat, Daten außer Haus etc.
Gibt es irgendwo noch Debug oder Protokoll-Funktionen die ich mit ALexa local prüfen kann ?
Danke !
Kai
Hi,
eine Trick gibt es da eigentlich nicht, aber welchen der InputAdapter benutzt du denn?
Hallo,
ich verzweifle… Nach 2 Tagen hab ich es immer noch nicht geschafft, irgendwelche Objekte mit der Alexa App suche zu finden. Es ist wie bei meinen Vorrednern. Das Device geht auf discovery, wird aber nicht entdeckt.
Hab die node js 8.12.0 mit der 4.6.1 NPM in einer ioBroker Installation 3.4.7 und dem 1.6.0 node-red Adapter im Einsatz.
Das ganze läuft auf eine RPI 3B+ Linux jessie lite 4.14.69-V7+ aus dem piVCCU-Image 2.35.16-36.
Vielleicht kann mir jemand helfen. Mit den diversen Cloud-Lösungen werden die Objekte gefunden aber ich finde diese Lösung einfach zu gut und würde sie gerne weiter testen.
Die Log´s sind unauffällig soweit ich das beurteilen kann.
Danke !
painless
Hallo Blackeye
danke für Deine schnelle Antwort! Welchen Input Adapter meinst Du ?
Ich hab die Alexa App auf einem Fire und einen Echo 2. Gen und da hab ich gelesen, dass dort die Device suche (noch) nicht funktioniert. Aber vom Fire muss es doch klappen, oder ?
Im ioBroker hab ich den o.g. node-red Adapter 1.6.0 und das node-red-contrib-alexa-local über die node-red Oberfläche installiert.
Weiter laufen die Homematic hmrega und hmrpc, discovery und admin Adapter. Sonst nix weiter.
Keine weiteren Cloud oder aktivierten Skills, wie Du es hier auch so beschreibst.
Mein Flow startet mit dem Input der Alexa-local. Ich hab es so verstanden, dass der Name dieses Inputs der Rufname in Alexa ist. Dann noch einen Switch, da ich damit ein Licht schalten möchte und dann die Verzweigung auf das entsprechende Homematic Objekt.
Hab ich da irgendetwas überlesen ?
Danke !
painless
Hallo,
ich verzweifle… Nach 2 Tagen hab ich es immer noch nicht geschafft, irgendwelche Objekte mit der Alexa App suche zu finden. Es ist wie bei meinen Vorrednern. Das Device geht auf discovery, wird aber nicht entdeckt.
Hab die node js 8.12.0 mit der 4.6.1 NPM in einer ioBroker Installation 3.4.7 und dem 1.6.0 node-red Adapter im Einsatz.
Das ganze läuft auf eine RPI 3B+ Linux jessie lite 4.14.69-V7+ aus dem piVCCU-Image 2.35.16-36.
Vielleicht kann mir jemand helfen. Mit den diversen Cloud-Lösungen werden die Objekte gefunden aber ich finde diese Lösung einfach zu gut und würde sie gerne weiter testen.
Die Log´s sind unauffällig soweit ich das beurteilen kann.
Danke !
painless