@isnoahoy: Danke für deine Rückmeldung. Ja da bin ich gerade dran und schaue mir das nochmal inruhe durch. Ich versuche aktuell aus den "usart_nrf3" denn genauen Aufbau des Protokolls nachzuverfolgen.
Stefan T. schrieb: > Hallo Josef J., > > Bei Dir sind drei WR konfiguriert, zumindest will er die alle abfragen. > Bitte entferne alle überflüssigen Werte aus der Setup Seite für die WR 2 > und 3. Dann sollte es m.E. nach einem Reboot funktionieren. > > Je nach Version werden die Werte beim Erase EEPROM nicht mit sinnvollen > Werten gefüllt. Ich glaube Lukas P. hat das in der v0.4.20 die Tage erst > angepaßt / gefixt. Vielen Dank, das hatte ich gerade zufällig selber probiert. Leider ohne Erfolg.
Hallo zusammen, und vielen Dank für euere tolle Arbeit. Hab mir vor 2 Tagen bei komputer.de die Chips bestellt: 1 Stk. nRF24L01+ PA SMA mit Antenne 3.20EUR 1 Stk. ESP32 Development board NodeMCU kompatibel 6.50EUR Heute zusammengelötet, am Mac mini M1 programmiert und es läuft bestens mit HM-1200. Dabei stellte ich fest, daß von meinen 4 Solarpanelen die beiden „älteren“ von 2016 nur noch ein Fünftel der Leistung bringen. Nach nur 6 Jahren! Gruselig… Grüße, Matze
Beitrag #7112309 wurde vom Autor gelöscht.
Kann jemand was dazu sagen wie man das zu verstehen hat? Habe folgendes nachgestellt: case NET_LIMIT_ACTIVE_POEWR: // NET_LIMIT_ACTIVE_POEWR = 24, case NET_LIMIT_POEWR: // NET_LIMIT_POEWR = 3, SubCmd = Type_ActivePowerContr; //Limit active power = 11, MainCmd = DEVCONTROL_ALL; // #define DEVCONTROL_ALL 0x51 break;
1 | 2022-06-29 18:13:17.628811 Transmit 11 | 51 74 40 33 29 78 56 34 12 0b 7c |
2 | 2022-06-29 18:13:17.684810 Received 11 bytes channel 61: d1 74 40 33 29 74 40 33 29 81 50 |
3 | Error while retrieving data: unpack requires a buffer of 2 bytes |
Am ende steht eine 0x81, wäre jetzt hier der Zeitpunkt Daten nachzusenden? https://github.com/lumapu/ahoy/blob/main/doc/hoymiles-format-description.txt (Zeile: 520) Ist ja ähnlich aufgebaut. Ich habe zwar in der Vergangenheit gelesen das jmd. herausgefunden hat (oder mutmaßt) das wenn die ID vom WR zweimal hintereinander steht, soll es sich um ein Verworfenes Packet handeln.
:
Bearbeitet durch User
Bei mir waren es zB einmal Leerzeichen nach den eingegeben Werten, die mit abgespeichert wurden. Copy-paste Fehler.
Bei mir waren es zB einmal Leerzeichen nach den eingegeben Werten, die mit abgespeichert wurden. Copy-paste Fehler.
Hallo Josef J., Hfhausen schrieb: > Bei mir waren es zB einmal Leerzeichen nach den eingegeben Werten, die > mit abgespeichert wurden. Copy-paste Fehler. Das könnte auch eine Ursache sein, probier das doch mal aus bzw. überprüfe das nochmal. Es gab auch schon Probleme bei vertauschten Anschlüssen des nRF24L01+ per SPI an den ESP8266, also Verkabelung und Konfiguration nochmal prüfen. Ich entsinne mich daß Lukas P. die Default Werte in der v0.4.20 geändert hat, da er damit mehr Erfolg hatte: https://github.com/grindylow/ahoy/issues/36#issuecomment-1169020584 Desweiteren wäre es hilfreich den ESP8266 per USB Kabel am Computer/Laptop angeschloßen zu lassen. Wenn Du unter Tools > Port den Anschluß prüfst und dann die Serial Console aufmachst, solltest Du nach einem Reset ein etwas ausführlicheres Debug Log bekommen. Die Statistik auf der WebSeite in Deinem Screenshot sagt an der Stelle leider nicht mehr aus. Das Debug Log enthält auch Informationen zum Anschluß des nRF24L01+ und dessen Einstellungen.
Daniel R. schrieb: > Ich glaube das der WR in der Lage ist sogar einzelne Strings > kontrolliert abzuschalten, oder Einzuschalten. > Aus irgendeinen Grund wird bei der Übergabe dieser Funktion die 'SubCmd' > mit Bit-Operatoren verarbeitet. > ... Könnt ihr aber auch selbst unten lesen. > > temp_dat[9] = SubCmd & 0XFF00 >> 8; //5a5a > temp_dat[10] = SubCmd & 0XFF; > temp_dat[11] = MIMajor[PortNO].Property.Power_Limit * 10 / > (EVERY_PORT_POWER * > (UsartNrf_GetInvterType(MIMajor[PortNO].Property.Pre_Id))); //Power > limit percentage > temp_dat[12] = MIMajor[PortNO].Property.Power_Limit >> 8; > //High 8-bit power limit > temp_dat[13] = MIMajor[PortNO].Property.Power_Limit & 0x00ff; > //Low power limit 8 bits > temp_dat[14] = Get_crc_xor(&temp_dat[0], 14); //CRC > i = ForwardSubstitution(&Uart_SendBuffer[1], &temp_dat[0], 15); > //forward substitution > } Das habe ich schon beschrieben und implementiert, siehe meinen Beitrag v. früher: - nach % limitieren SubCMD=5a5a:limit percentage:,CRC - nach abs.Leistung limitieren: SubCMD=5a5a:limit percentage(egal wieviel):Hi-bit Limit:Lo-bit Limit:CRC
mein esp8266 lief nie länger als 1h.
Fehler beim Debuggen:
--------------- CUT HERE FOR EXCEPTION DECODER ---------------
Exception (29):
epc1=0x4000df64 epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000000
depc=0x00000
000
>>>stack>>>
ctx: sys
sp: 3fffec10 end: 3fffffb0 offset: 0190
3fffeda0: 00000005 3ffee120 00000002 40100524
3fffedb0: 402329d7 3ffefb6c 3ffea5ef 4023296c
3fffedc0: 00000002 40232913 00000002 40231a68
3fffedd0: 40231a91 3fffee80 3ffee120 00000016
3fffede0: 4022f4f4 3fffee80 3ffedfc8 3ffed9c0
3fffedf0: 3ffeb1d8 3fffee80 3fffee80 00000000
3fffee00: 2d525744 5f363131 46393345 00004334
3fffee10: 00000000 3ffecc90 00000020 40100bdc
3fffee20: 4022b859 4022cd31 3ffed8d0 00000000
3fffee30: ffffffc0 3ffedadc 3ffeb1e8 3ffee120
3fffee40: 3ffed020 00000020 00000000 402301ef
3fffee50: 00000000 3ffefb6c ffffffc0 00000000
3fffee60: 00000000 3ffee120 3ffee800 304baf06
3fffee70: 4023bfc2 3ffefb6c 0000000e 3ffee014
3fffee80: 00000000 00310a0a 00640100 00000053
3fffee90: 3ffeb1fc 000000d6 3ffeb21f 3ffeb1f0
3fffeea0: 00000000 3ffeb1fc 3ffeb20c 3ffeb219
3fffeeb0: 00000000 00000000 3ffeb292 3ffeb2a8
3fffeec0: 3ffeb25b 3ffeb277 00000000 3ffeb225
3fffeed0: 00000000 00000000 00000020 00000000
3fffeee0: 3ffefe14 4022fc5e 3ffed020 3ffefb6c
3fffeef0: 00000000 3ffee120 3ffed020 3ffeb1d8
3fffef00: 3ffeb1d8 000000fe 00000000 00000020
3fffef10: 00000000 3ffeb1e2 40243313 3ffed020
3fffef20: 3ffeb1cc 3fffdcc0 3ffe9730 3ffe9730
3fffef30: 00000080 3ffed020 00000000 3ffe85d8
3fffef40: 40242bd3 3fffdab0 00000000 40211f56
3fffef50: 3ffe9730 40000f49 3fffdab0 40000f49
3fffef60: 40000e19 0005aef1 00000000 00000005
3fffef70: 60000600 aa55aa55 000000ed 40105539
3fffef80: 4010553f 00000000 00000005 40100b8c
3fffef90: 4010000d 8742b1f0 0005aef1 401000ac
3fffefa0: 00000000 3fffef3c 00000000 3ffffec8
3fffefb0: 3fffffc0 00000000 00000000 feefeffe
3fffefc0: feefeffe feefeffe feefeffe feefeffe
3fffefd0: feefeffe feefeffe feefeffe feefeffe
3fffefe0: feefeffe feefeffe feefeffe feefeffe
3fffeff0: feefeffe feefeffe feefeffe feefeffe
3ffff000: feefeffe feefeffe feefeffe feefeffe
3ffff010: feefeffe feefeffe feefeffe feefeffe
3ffff020: feefeffe feefeffe feefeffe feefeffe
3ffff030: feefeffe feefeffe feefeffe feefeffe
3ffff040: feefeffe feefeffe feefeffe feefeffe
3ffff050: feefeffe feefeffe feefeffe feefeffe
3ffff060: feefeffe feefeffe feefeffe feefeffe
3ffff070: feefeffe feefeffe feefeffe feefeffe
3ffff080: feefeffe feefeffe feefeffe feefeffe
3ffff090: feefeffe feefeffe feefeffe feefeffe
3ffff0a0: feefeffe feefeffe feefeffe feefeffe
3ffff0b0: feefeffe feefeffe feefeffe feefeffe
3ffff0c0: feefeffe feefeffe feefeffe feefeffe
3ffff0d0: feefeffe feefeffe feefeffe feefeffe
3ffff0e0: feefeffe feefeffe feefeffe feefeffe
3ffff0f0: feefeffe feefeffe feefeffe feefeffe
3ffff100: feefeffe feefeffe feefeffe feefeffe
3ffff110: feefeffe feefeffe feefeffe feefeffe
3ffff120: feefeffe feefeffe feefeffe feefeffe
3ffff130: feefeffe feefeffe feefeffe feefeffe
3ffff140: feefeffe feefeffe feefeffe feefeffe
3ffff150: feefeffe feefeffe feefeffe feefeffe
3ffff160: feefeffe feefeffe feefeffe feefeffe
3ffff170: feefeffe feefeffe feefeffe feefeffe
3ffff180: feefeffe feefeffe feefeffe feefeffe
3ffff190: feefeffe feefeffe feefeffe feefeffe
3ffff1a0: feefeffe feefeffe feefeffe feefeffe
3ffff1b0: feefeffe feefeffe feefeffe feefeffe
3ffff1c0: feefeffe feefeffe feefeffe feefeffe
3ffff1d0: feefeffe feefeffe feefeffe feefeffe
3ffff1e0: feefeffe feefeffe feefeffe feefeffe
3ffff1f0: feefeffe feefeffe feefeffe feefeffe
3ffff200: feefeffe feefeffe feefeffe feefeffe
3ffff210: feefeffe feefeffe feefeffe feefeffe
3ffff220: feefeffe feefeffe feefeffe feefeffe
3ffff230: feefeffe feefeffe feefeffe feefeffe
3ffff240: feefeffe feefeffe feefeffe feefeffe
3ffff250: feefeffe feefeffe feefeffe feefeffe
3ffff260: feefeffe feefeffe feefeffe feefeffe
3ffff270: feefeffe feefeffe feefeffe feefeffe
3ffff280: feefeffe feefeffe feefeffe feefeffe
3ffff290: feefeffe feefeffe feefeffe feefeffe
3ffff2a0: feefeffe feefeffe feefeffe feefeffe
3ffff2b0: feefeffe feefeffe feefeffe feefeffe
3ffff2c0: feefeffe feefeffe feefeffe feefeffe
3ffff2d0: feefeffe feefeffe feefeffe feefeffe
3ffff2e0: feefeffe feefeffe feefeffe feefeffe
3ffff2f0: feefeffe feefeffe feefeffe feefeffe
3ffff300: feefeffe feefeffe feefeffe feefeffe
3ffff310: feefeffe feefeffe feefeffe feefeffe
3ffff320: feefeffe feefeffe feefeffe feefeffe
3ffff330: feefeffe feefeffe feefeffe feefeffe
3ffff340: feefeffe feefeffe feefeffe feefeffe
3ffff350: feefeffe feefeffe feefeffe feefeffe
3ffff360: feefeffe feefeffe feefeffe feefeffe
3ffff370: feefeffe feefeffe feefeffe feefeffe
3ffff380: feefeffe feefeffe feefeffe feefeffe
3ffff390: feefeffe feefeffe feefeffe feefeffe
3ffff3a0: feefeffe feefeffe feefeffe feefeffe
3ffff3b0: feefeffe feefeffe feefeffe feefeffe
3ffff3c0: feefeffe feefeffe feefeffe feefeffe
3ffff3d0: feefeffe feefeffe feefeffe feefeffe
3ffff3e0: feefeffe feefeffe feefeffe feefeffe
3ffff3f0: feefeffe feefeffe feefeffe feefeffe
3ffff400: feefeffe feefeffe feefeffe feefeffe
3ffff410: feefeffe feefeffe feefeffe feefeffe
3ffff420: feefeffe feefeffe feefeffe feefeffe
3ffff430: feefeffe feefeffe feefeffe feefeffe
3ffff440: feefeffe feefeffe feefeffe feefeffe
3ffff450: feefeffe feefeffe feefeffe feefeffe
3ffff460: feefeffe feefeffe feefeffe feefeffe
3ffff470: feefeffe feefeffe feefeffe feefeffe
3ffff480: feefeffe feefeffe feefeffe feefeffe
3ffff490: feefeffe feefeffe feefeffe feefeffe
3ffff4a0: feefeffe feefeffe feefeffe feefeffe
3ffff4b0: feefeffe feefeffe feefeffe feefeffe
3ffff4c0: feefeffe feefeffe feefeffe feefeffe
3ffff4d0: feefeffe feefeffe feefeffe feefeffe
3ffff4e0: feefeffe feefeffe feefeffe feefeffe
3ffff4f0: feefeffe feefeffe feefeffe feefeffe
3ffff500: feefeffe feefeffe feefeffe feefeffe
3ffff510: feefeffe feefeffe feefeffe feefeffe
3ffff520: feefeffe feefeffe feefeffe feefeffe
3ffff530: feefeffe feefeffe feefeffe feefeffe
3ffff540: feefeffe feefeffe feefeffe feefeffe
3ffff550: feefeffe feefeffe feefeffe feefeffe
3ffff560: feefeffe feefeffe feefeffe feefeffe
3ffff570: feefeffe feefeffe feefeffe feefeffe
3ffff580: feefeffe feefeffe feefeffe feefeffe
3ffff590: feefeffe feefeffe feefeffe feefeffe
3ffff5a0: feefeffe feefeffe feefeffe feefeffe
3ffff5b0: feefeffe feefeffe feefeffe feefeffe
3ffff5c0: feefeffe feefeffe feefeffe feefeffe
3ffff5d0: feefeffe feefeffe feefeffe feefeffe
3ffff5e0: feefeffe feefeffe feefeffe feefeffe
3ffff5f0: feefeffe feefeffe feefeffe feefeffe
3ffff600: feefeffe feefeffe feefeffe feefeffe
3ffff610: feefeffe feefeffe feefeffe feefeffe
3ffff620: feefeffe feefeffe feefeffe feefeffe
3ffff630: feefeffe feefeffe feefeffe feefeffe
3ffff640: feefeffe feefeffe feefeffe feefeffe
3ffff650: feefeffe feefeffe feefeffe feefeffe
3ffff660: feefeffe feefeffe feefeffe feefeffe
3ffff670: feefeffe feefeffe feefeffe feefeffe
3ffff680: feefeffe feefeffe feefeffe feefeffe
3ffff690: feefeffe feefeffe feefeffe feefeffe
3ffff6a0: feefeffe feefeffe feefeffe feefeffe
3ffff6b0: feefeffe feefeffe feefeffe feefeffe
3ffff6c0: feefeffe feefeffe feefeffe feefeffe
3ffff6d0: feefeffe feefeffe feefeffe feefeffe
3ffff6e0: feefeffe feefeffe feefeffe feefeffe
3ffff6f0: feefeffe feefeffe feefeffe feefeffe
3ffff700: feefeffe feefeffe feefeffe feefeffe
3ffff710: feefeffe feefeffe feefeffe feefeffe
3ffff720: feefeffe feefeffe feefeffe feefeffe
3ffff730: feefeffe feefeffe feefeffe feefeffe
3ffff740: feefeffe feefeffe feefeffe feefeffe
3ffff750: feefeffe feefeffe feefeffe feefeffe
3ffff760: feefeffe feefeffe feefeffe feefeffe
3ffff770: feefeffe feefeffe feefeffe feefeffe
3ffff780: feefeffe feefeffe feefeffe feefeffe
3ffff790: feefeffe feefeffe feefeffe feefeffe
3ffff7a0: feefeffe feefeffe feefeffe feefeffe
3ffff7b0: feefeffe feefeffe feefeffe feefeffe
3ffff7c0: feefeffe feefeffe feefeffe feefeffe
3ffff7d0: feefeffe feefeffe feefeffe feefeffe
3ffff7e0: feefeffe feefeffe feefeffe feefeffe
3ffff7f0: feefeffe 00000000 feefeffe 00000100
3ffff800: 000000d0 00000000 40105385 00000100
3ffff810: 000000d0 00000000 40105385 000000ee
3ffff820: 00000129 00000001 40105385 3ffed7f8
3ffff830: 3ffed780 00000001 40105385 3ffed7f8
3ffff840: 3ffe9635 40105437 3ffed0c0 00000100
3ffff850: 00000005 00000000 00000020 401001c8
3ffff860: 00007fff 00000000 00000005 000000fe
3ffff870: 0000005c 00000001 40105385 3ffed7f8
3ffff880: 3ffed780 3ffed020 401033c2 00000100
3ffff890: 00007fff 01698d04 3ffed9c0 40102f08
3ffff8a0: 40104f6a 3ffed7f8 00000000 401001c8
3ffff8b0: 00007fff 401048b9 3ffed7f8 00000100
3ffff8c0: 3ffe9ec8 7fffffff 00002200 00000001
3ffff8d0: 40104e6d 3ffed7f8 3ffeccd8 00040000
3ffff8e0: 53002200 00000030 00000005 401021a0
3ffff8f0: 40105145 00080000 00000002 3fffc278
3ffff900: 40103412 3ffed0c0 00000022 00000014
3ffff910: 00007fff 00000000 3ffed9c0 40102f08
3ffff920: 3ffe9ec8 2c9f0300 4000050c 3fffc278
3ffff930: 401030e4 3fffc200 00000022 00000100
3ffff940: 40219018 00000030 00000010 ffffffff
3ffff950: 40219013 00000030 00303032 3ffffc52
3ffff960: 00000003 00000003 4021b6bc 3ffffba0
3ffff970: 00000000 00000000 3ffffb33 3ffffc50
3ffff980: 3ffffc50 00000002 00000003 00000030
3ffff990: 40245675 00000030 00000010 ffffffff
3ffff9a0: 00002000 00000000 3ffed480 00000020
3ffff9b0: 3ffed4a0 00000042 3fff353e 0000008a
3ffff9c0: 00000002 00000000 0000000a 00000000
3ffff9d0: 00000002 00000000 40243d2f 00000000
3ffff9e0: ffffffff 00000000 3ffe9781 00000000
3ffff9f0: 40243d7e 3ffeccd8 3ffefb6c 00000001
3ffffa00: 40243e8a 3ffeccd8 3ffefb6c 3ffeccd8
3ffffa10: 00000005 00000005 00000008 3fff3620
3ffffa20: 3ffe9632 40242e3b 3ffeccd8 3fff3604
3ffffa30: 00000000 4022c477 3ffee120 3ffefb6c
3ffffa40: 00000000 00000002 00000000 3ffeccd8
3ffffa50: 3fff363a 40105a7b 3fff1f0c 3ffef57c
3ffffa60: 3ffefe14 00000000 3ffffba0 4021b780
3ffffa70: 4021b6bc 4021d7e5 3fff1f0c 3ffef57c
3ffffa80: 00000005 00000000 00000020 401001c8
3ffffa90: 3ffffb2f 00000000 00000005 401021a0
3ffffaa0: 3ffe9635 40105437 3ffed020 4021da13
3ffffab0: 40102d2b 3ffed020 00000000 4021de6e
3ffffac0: fffffff5 3000f717 3ffed96c 40102f08
3ffffad0: 3ffe9ed4 00000000 00000000 3ffef8b0
3ffffae0: fffffff5 3000f717 401033c2 00000100
3ffffaf0: 3ffe9ed4 7fffffff 00002200 00000001
3ffffb00: 00000001 00000080 00302064 3ffe8368
3ffffb10: 3ffe9ed4 00000000 0000001f 3000f717
3ffffb20: 3ffe9ec8 2c9f0300 4000050c 3fffc278
3ffffb30: 401030e4 3fffc200 00000022 401001c8
3ffffb40: 402120b4 00000030 00000008 ffffffff
3ffffb50: 40213564 000c3500 00000647 13a71553
3ffffb60: 00000003 4020eb18 0000007f 00000080
3ffffb70: 000000b0 3fffc6fc 00000001 3ffffc91
3ffffb80: 00000003 00000000 fffffffc 00000030
3ffffb90: fffffff5 2f5066c1 401033c2 00000100
3ffffba0: 3ffe9ed4 7fffffff 00002200 00000001
3ffffbb0: 00000001 00000080 3ffed020 401001c8
3ffffbc0: 3ffe9ed4 3ffed020 3fffc228 2f5066c1
3ffffbd0: 3ffe9ec8 2c9f0300 4000050c 3fffc278
3ffffbe0: 401030e4 3fffc200 00000022 ffffffff
3ffffbf0: 4021353d 00000030 00000010 ffffffff
3ffffc00: 00000000 00000002 3ffffc51 40213564
3ffffc10: 3ffffc52 4020eb18 3fffc228 40105cd1
3ffffc20: 00000000 00000000 0000001f 401001c8
3ffffc30: 00000002 40252c3c 3fffc228 40105cd1
3ffffc40: 4000050c 40252c3c 00000000 4020fce0
3ffffc50: 402023ad 00000030 0000001c ffffffff
3ffffc60: 402023aa 0000002f 00000013 00000190
3ffffc70: 60000120 00000000 0000007f 00000080
3ffffc80: 00000000 3ffe87fc 0000a7f0 3fff12b8
3ffffc90: 0000000b 3fff12e0 3fff12a4 00000030
3ffffca0: 40100348 00000000 00000004 401010e8
3ffffcb0: 40100348 00000000 00000004 401010e8
3ffffcc0: 40100348 00000000 00000004 401010e8
3ffffcd0: 40100348 00000001 00000004 401010e8
3ffffce0: 00000005 00000000 00000020 401001c8
3ffffcf0: 40100348 00000022 00000005 401021a0
3ffffd00: 3ffe9635 40105437 3ffed020 4020c230
3ffffd10: 40102d2b 3ffed020 0000001f 401001c8
3ffffd20: 00000000 304c3b2f 3ffed9c0 40102f08
3ffffd30: 3ffe9ed4 00000000 00000000 401001c8
3ffffd40: 00000000 304c3b2f 401033c2 00000100
3ffffd50: 3ffe9ed4 7fffffff 00002200 00000001
3ffffd60: 00000001 00000080 3fffc228 40105cd1
3ffffd70: 3ffe9ed4 00000030 00000010 304c3b2f
3ffffd80: 3ffe9ec8 2c9f0300 4000050c 3fffc278
3ffffd90: 401030e4 3fffc200 00000022 fffffffe
3ffffda0: 40000671 00000030 00000010 ffffffff
3ffffdb0: 00000000 7d0ada90 0e4bd28b 00000000
3ffffdc0: 00004bc6 7d0ada90 00000000 fffffffe
3ffffdd0: 000033c3 3fffc6fc 2c80da90 304c43d7
3ffffde0: 4bc6a7f0 3ffeec70 3ffef178 00000030
3ffffdf0: 40204d64 00000030 00000010 ffffffff
3ffffe00: 40204d64 3ffef30c 2ade07a0 40237b0d
3ffffe10: 00000000 00000000 00000000 fffffffe
3ffffe20: ffffffff 3fffc6fc 00000001 3ffef164
3ffffe30: 00000000 00000000 0000001f 401001c8
3ffffe40: 00000000 304aab27 3fffc228 4020b5a2
3ffffe50: 00000001 4bc6a7f0 75c28f5c 0e4bd288
3ffffe60: 00000001 00000000 4bc6a7f0 00000000
3ffffe70: 3ffeec70 00000000 401002dd 00000001
3ffffe80: 000c5d40 00000000 00001388 4020c1c5
3ffffe90: 00000001 4bc6a7f0 7d70a3d7 0e4bd291
3ffffea0: 00000001 00000000 4bc6a7f0 00000000
3ffffeb0: 00000000 00000000 401002dd 00000001
3ffffec0: 000c5d40 3fff12b8 3ffef164 3ffef178
3ffffed0: 3ffeec70 00000000 3ffef164 3ffef178
3ffffee0: 3ffeec70 3ffeef70 3ffef164 40204f7c
3ffffef0: 00000000 3fffdad0 3ffef178 00000030
3fffff00: 00000000 3fffdad0 3ffef178 00000030
3fffff10: 6f697461 feef006e feefeffe 0000effe
3fffff20: 00000000 0023002f 00000000 00000000
3fffff30: 0024002f 00000000 00000000 0017001f
3fffff40: 00000000 00000000 0010001f 00000000
3fffff50: 30372e30 00572030 000000b0 3ffef178
3fffff60: 007a1200 2b2c49c4 00000000 3fff1704
3fffff70: 00000000 3fff16ec 3fff16ec 00000010
3fffff80: 00000000 00000000 00000001 401001c8
3fffff90: 3fffdad0 00000000 3ffef164 401001e9
3fffffa0: feefeffe feefeffe 3ffef164 4021211a
<<<stack<<<
--------------- CUT HERE FOR EXCEPTION DECODER ---------------
Daniel R. schrieb: >
1 | 2022-06-29 18:13:17.628811 Transmit 11 | 51 74 40 33 29 78 56 34 |
2 | > 12 0b 7c |
3 | > 2022-06-29 18:13:17.684810 Received 11 bytes channel 61: d1 74 40 33 29 |
4 | > 74 40 33 29 81 50 |
5 | > Error while retrieving data: unpack requires a buffer of 2 bytes |
6 | > |
> > Am ende steht eine 0x81, wäre jetzt hier der Zeitpunkt Daten > nachzusenden? Deine Frage habe ich nicht verstanden, was genau möchtest/erwartest du nachzusenden? nach CMD 0x51 sollte d1:WR|WR:5a:5a:d1 kommen und fertig, danach kommt nichts mehr. Und warum bei dir eine 0x81 kommt verstehe ich nicht.
@Daniel R. - nach abs.Leistung limitieren: SubCMD=5a5a:limit percentage(egal wieviel):Hi-bit Limit:Lo-bit Limit:CRC Limitleistung wird mit 1 DEC als int gesendet, zB. 123.4 Watt schickst du als 1234, darum hi/low bytes
Nur zu Info ich habe immer noch ein HM. Aktuell schaut es so aus:
1 | 2022-06-29 22:32:05.965908 Transmit 15 | 51 74 40 33 29 78 56 34 12 5a 5a 02 01 50 24 |
2 | 2022-06-29 22:32:07.203038 Transmit 15 | 51 74 40 33 29 78 56 34 12 5a 5a 02 01 50 24 |
3 | 2022-06-29 22:32:08.439419 Transmit 15 | 51 74 40 33 29 78 56 34 12 5a 5a 02 01 50 24 |
Testweise auch mit 20%
1 | 2022-06-29 22:34:46.838015 Transmit 15 | 51 74 40 33 29 78 56 34 12 5a 5a 14 01 50 32 |
2 | 2022-06-29 22:34:48.077215 Transmit 15 | 51 74 40 33 29 78 56 34 12 5a 5a 14 01 50 32 |
3 | 2022-06-29 22:34:49.311756 Transmit 15 | 51 74 40 33 29 78 56 34 12 5a 5a 14 01 50 32 |
4 | 2022-06-29 22:34:50.547037 Transmit 15 | 51 74 40 33 29 78 56 34 12 5a 5a 14 01 50 32 |
Bekomme halt kein Recieve. Ziyat T. schrieb: > Deine Frage habe ich nicht verstanden, was genau möchtest/erwartest du > nachzusenden? Ich hab es aus den Infos so verstanden das man erstmal ein Datenpaket zum WR schickt. Wenn dieser mit 0x81 Antworter können die nächsten Daten raus verschickt werden. Hatte ich hier im unteren Absatz geschrieben: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
:
Bearbeitet durch User
Daniel R. schrieb: > Nur zu Info ich habe immer noch ein HM. Ja ich weiss, vielleicht gehts ja auch mit HM > Testweise auch mit 20% > [code]2022-06-29 22:34:46.838015 Transmit 15 | 51 74 40 33 29 78 56 34 > 12 5a 5a 14 01 50 32 Ist hier nach 0x14 (20%) die CRC 0x1 richtig? glaube nicht. Wenn du nach % willst, musst du nach 0x14 die crc schicken, keine bytes mehr. >2022-06-29 22:32:07.203038 Transmit 15 | 51 74 40 33 29 78 56 34 12 5a 5a >02 01 50 24 Hier schikst du 0x2 als %, wird ignoriert egal, weil danach hi-byte 0x1,low-byte 0x50 der Limitleistung kommen, ist hier die crc 0x24 richtig?
Hallo Ziyat, erstmal danke das du dir Zeit für mich nimmst! :) Ziyat T. schrieb: >> Testweise auch mit 20% >> 2022-06-29 22:34:46.838015 Transmit 15 | 51 74 40 33 29 78 56 34 >> 12 5a 5a 14 01 50 32 > > Ist hier nach 0x14 (20%) die CRC 0x1 richtig? glaube nicht. Wenn du nach > % willst, musst du nach 0x14 die crc schicken, keine bytes mehr. Das würde dann bei mir so aussehen:
1 | 2022-06-30 05:43:01.828959 Transmit 13 | 51 74 40 33 29 78 56 34 12 5a 5a 14 63 |
Auch hier bekomme ich kein Antwort vom WR. >>2022-06-29 22:32:07.203038 Transmit 15 | 51 74 40 33 29 78 56 34 12 5a 5a >02 01 > 50 24 > > Hier schikst du 0x2 als %, wird ignoriert egal, weil danach hi-byte > 0x1,low-byte 0x50 der Limitleistung kommen, ist hier die crc 0x24 > richtig? Das weiß ich nicht, ich habe bei der CRC Algorithmus nichts geändert. Nutze von Ahoy die rpi Version. - Wenn ich nur die Daten (DC/AC) vom WR Anfordern möchte, geht das ohne Probleme. Daher vermute ich das die CRC Berechnung passen wird.
:
Bearbeitet durch User
Hallo dax, ja wir beobachten das Problem der ESP8266 Variante schon seit längerem mit Argwohn. Wir haben auch schon einige Male einen Stack Trace in Github hochgeladen aber außer des/r nun stark optimierten Interrupt Handler haben wir bisher noch keinen Plan warum es so häufig zu WDT (Watch Dog Timer) Resets kommt. * Loosing WiFi connection after X minutes #15 https://github.com/grindylow/ahoy/issues/15 hier findet sich auch eine Anleitung verlinkt, nach der Du mit dem Binary Deinen Stack Trace decodieren kannst. * Zeitkritikalität in der Haupt-Loop? #24 https://github.com/grindylow/ahoy/issues/24 hier haben wir uns dem Thema Interrupt und State Machine gewidmet. * ESP8266: Discussion Verkabelung / Pinout #36 https://github.com/grindylow/ahoy/issues/36 hier hat Lukas P. zuletzt berichtet daß es bei ihm nach Vertauschen (!) der Pins für CE und IRQ stabiler lief. * Stabilität ESP8266 #83 https://github.com/grindylow/ahoy/issues/83 und hier diskutieren wir aktuell ob wir auch an der nRF24 Bibliothek Anpassungen vornehmen müssen/sollen. Alternativ zu den oben genannten Issues kannst Du gerne mal eines der anderen "Tools" ausprobieren (z.B. die offenbar problemlos laufende Raspberry Pi Variante von Jan-Jonas S., oder Hubi's Code für den ESP8266) oder die m.E. sehr saubere ESP32 Implementierung von Thomas B. unter https://github.com/tbnobody/OpenDTU Bei mir steckt der Code m.E. immer wieder in der WebServer Routine fest, da er einige Requests beantworten muß und dann stürzt er ab. Das ließe sich evtl. durch die AsyncWebServer Variante ersetzen, wie bei OpenDTU ? Oder es liegt daran, daß er mit zu häufigen Anfragen an RF24, MQTT und WebServer einfach überlastet wird. Er steckt meist in irgendwelchen ummalloc Routinen beim WDT Reset und daher vermute ich daß es etwas mit dem etwas zu offenherzigen Einsatz der String Klasse zu tun haben könnte, hier wird nämlich fleißig vom Flash/Progmem ins RAM kopiert um dann wieder an die Adresse des Zielstrings (z.B. beim + / Concatenieren) die Einzelstrings zu kopieren. Das kann evtl. auch einige CPU Zyklen brauchen.
Hallo Ziyat T. & Daniel R., ja und ja beim MI-XXXX Wechselrichter heißt das Command 0x51 in usart_nrf.c/.h CONTROL_LOCK_MI__LIMIT_POWER_ONOFF und beim HM-Wechselrichter wird laut usart_nrf3.c/.h 0x51 als DEVCONTROL_ALL definiert. D.h. das Kommando sieht beim HM-XXXX etwas anders aus nach dem SubCmd. Bei der Antwort kommt wie Daniel R. bereits geschrieben hat ANSWER_DEVCONTROL_ALL (DEVCONTROL_ALL|0X80) also 0xD1. Bei den bereits analysierten und implementierten Anfragen an die HM-XXXX Inverter verwendet der Hersteller das REQ_ARW_DAT_ALL 0x15 Kommando und erwartet als Antwort ebenfalls das Komplement ANSWER_REQ_ARW_DAT_ALL (REQ_ARW_DAT_ALL|0X80) also 0x95. Für 0x15 sind die entsprechenden SubCmd's definiert als:
1 | typedef enum |
2 | { |
3 | InverterDevInform_Simple = 0, |
4 | InverterDevInform_All = 1, |
5 | GridOnProFilePara = 2, |
6 | HardWareConfig = 3, |
7 | SimpleCalibrationPara = 4, |
8 | SystemConfigPara = 5, |
9 | RealTimeRunData_Debug = 11, // 0x0B |
10 | RealTimeRunData_Reality = 12, // 0x0C |
11 | RealTimeRunData_A_Phase = 13, // 0x0D |
12 | RealTimeRunData_B_Phase = 14, // 0x0E |
13 | RealTimeRunData_C_Phase = 15, // 0x0F //�澯����-����δ���澯 |
14 | AlarmData = 17, // 0x11 //�澯����-ȫ������澯 |
15 | AlarmUpdate = 18, // 0x12 |
16 | RecordData = 19, // 0x13 |
17 | InternalData = 20, // 0x14 |
18 | GetLossRate = 21, // 0x15 |
19 | //dong 2020-06-15 |
20 | GetSelfCheckState = 30, // 0x1E |
21 | InitDataState = 0xff, |
22 | |
23 | } DataType; |
Hiervon verwenden wir bisher RealTimeRunData_Debug 0x0B um Daten zum Wechselrichter und seinen Ein- & Ausgängen abzufragen und Jan-Jonas S. hatte vor zwei/drei Wochen begonnen sich die AlarmData 0x11 bzw AlarmUpdate 0x12 anzusehen und dabei einige Status Events aus dem Wechselrichter "Logfile" abrufen können. Hier hatten wir ein Byte weiter hinten beobachtet das wir als Anzahl der "Logmeldungen" identifiziert hatten. @Daniel R. 0x81, 0x82, 0x84 etc. sind die Paketkennungen des jeweils letzten Antwortpaketes auf eine RealTimeRunData_Debug 0x0B SubCmd Anfrage gewesen. Dabei wird das SubCmd-Feld in der Antwort durch einen Paketzähler ersetzt und beim letzten Paket das Komplement (Paketzähler | 0x80) mitgeliefert, damit die DTU weiß dass dies das letzte Fragment / Paket war. > 2022-06-29 18:13:17.628811 Transmit 11 | >51< <74 40 33 29> <78 56 34 12> >0b< <7c> > 2022-06-29 18:13:17.684810 Received 11 bytes channel 61: >d1< <74 40 33 29> <74 40 33 29> >81< <50> Warum in Deiner Antwort als vorletztes Byte vor der CRC8 der Wert 0x81 auftaucht: Vielleicht ist es ja die Antwort 1 und als Komplement (Antwort | 0x80) = 0x81 ? Ob das einfach Okay oder gesetzt oder etwas ganz Anderes bedeutet müsstest DU anhand der Methoden im usart_nrf(3).c Code mal herausfinden.
Stefan T. schrieb: Danke Stefan T. (isnoahoy) ! Das hatte ich bisher übersehen. > typedef enum > { > InverterDevInform_Simple = 0, > InverterDevInform_All = 1, > GridOnProFilePara = 2, > HardWareConfig = 3, > SimpleCalibrationPara = 4, > SystemConfigPara = 5, > RealTimeRunData_Debug = 11, // 0x0B > RealTimeRunData_Reality = 12, // 0x0C > RealTimeRunData_A_Phase = 13, // 0x0D > RealTimeRunData_B_Phase = 14, // 0x0E > RealTimeRunData_C_Phase = 15, // 0x0F > AlarmData = 17, // 0x11 > AlarmUpdate = 18, // 0x12 > RecordData = 19, // 0x13 > InternalData = 20, // 0x14 > GetLossRate = 21, // 0x15 > //dong 2020-06-15 > GetSelfCheckState = 30, // 0x1E > InitDataState = 0xff, Hallo, hat jemand auch Payload Beschreibungen für die anderen Antworten ausser "RealTimeRunData_Debug = 11, // 0x0B" ? Hab gerade mal "17=AlarmData" am Laufen über alle WR mit Hubis Uralt Code und bekomme zur Zeit je WR bis zu 3 Payloads als Antwort (01,02,83).
Stefan T. schrieb: > Hallo dax, > ja wir beobachten das Problem der ESP8266 Variante schon seit längerem > mit Argwohn. Mein "Rekord" sind 1 Tag - 18 Std. Betriebszeit ohne Reset (Wemos D1 mini, separate 3,3V-Versorgung mit entsprechenden Kondensatoren für nRF24L01+-Modul). Aber auch immer wieder Resets nach deutlich kürzeren Zeitspannen. Es gibt bei meinem Aufbau Resets, bei denen das System einfach neu startet, aber auch "Abstürze", bei denen die Versorgungsspannung unterbrochen werden muss, um einen Neustart zu ermöglichen. Die Probleme mit der Stabilität von Aufbauten mit ESP8266-basierten Boards gibt es auch in anderen Projekten, z. B. dieser "Esp8266 Nodemcu Gaszähler Thingspeak"; spätestens nach einem Tag war ein Reset notwendig (https://fipsok.de/Projekt/gaszaehler-esp8266-nodemcu). In einem anderen Projekt zur Erfassung des Gasverbrauchs wird ausgeführt: "Mehrere erste Versuche mit nur einem Mikrocontroller vom Typ ESP8266 waren nicht erfolgreich, weil bei gleichzeitiger Benutzung der Webseite leider die Zählimpuls-Erkennung über Interrupt nicht ausreichend zuverlässig war. Die aktuelle Lösung verwendet deshalb zusätzlich zum verwendeten ESP8266 noch einen ATTINY84 Mikrocontroller für die zuverlässige Zählfunktion für insgesamt 4 Kanäle." (https://www.stall.biz/project/pulsecounter-2-komfortabel-verbraeuche-von-strom-wasser-gas-und-solar-messen). Den Teil mit dem Wemos D1 mini-Board habe ich getestet, er lief stabil. Das Projekt habe ich aber nicht weiterverfolgt, weil es Probleme mit der Impulserfassung am Gaszähler gab. Die ESP32-Variante würde ich gerne testen. Leider scheitere ich beim Kompilieren mit Visual Studio Code und der PlatformIO Extension...
Günter H. schrieb: > Die ESP32-Variante würde ich gerne testen. Leider scheitere ich beim > Kompilieren mit Visual Studio Code und der PlatformIO Extension... Hallo Günter, Woran scheiterst du da? Was ist die Fehlermeldung? Was passiert oder was passiert nicht?
Hallo, inzwischen habe ich die ESP8266 Variante zusammengebaut und erfolgreich mit der Arduino-Umgebung die Version 0.4.20 installiert, WLAN konfiguriert und die Seriennummer meines TSUN TSOL-M800 eingetragen. Aus den Forumsbeiträgen schließe ich, dass die SW zur Zeit nur für die HM-Modelle funktioniert, allerdings war auch schon eine positive Meldung für den TSUN dabei? Jetzt bin ich mir nicht sicher, ob es an der Software liegt, oder an meiner ESP-Verkabelung. Muss man für die WR-Hardware in der SW vor dem compilieren noch was ändern, oder wird die WR-Hardware anhand der Seriennummer erkannt. Um sicherzustellen, das meine ESP-Bastelei korrekt funktioniert, hier der Auszug der serial-Konsole: 10:43:56.941 -> ............................... 10:44:01.668 -> I: add inverter: MI-800, SN: 11417xxxxxxxx 10:44:04.451 -> I: RF24 Amp Pwr: RF24_PA_MIN 10:44:04.451 -> I: Radio Config: 10:44:04.451 -> SPI Frequency = 1 Mhz 10:44:04.451 -> Channel = 3 (~ 2403 MHz) 10:44:04.451 -> RF Data Rate = 250 KBPS 10:44:04.451 -> RF Power Amplifier = PA_MIN 10:44:04.451 -> RF Low Noise Amplifier = Enabled 10:44:04.451 -> CRC Length = 16 bits 10:44:04.451 -> Address Length = 5 bytes 10:44:04.451 -> Static Payload Length = 32 bytes 10:44:04.451 -> Auto Retry Delay = 250 microseconds 10:44:04.483 -> Auto Retry Attempts = 0 maximum 10:44:04.483 -> Packets lost on 10:44:04.483 -> current channel = 0 10:44:04.483 -> Retry attempts made for 10:44:04.483 -> last transmission = 0 10:44:04.483 -> Multicast = Disabled 10:44:04.483 -> Custom ACK Payload = Disabled 10:44:04.483 -> Dynamic Payloads = Enabled 10:44:04.483 -> Auto Acknowledgment = Disabled 10:44:04.483 -> Primary Mode = RX 10:44:04.483 -> TX address = 0xdeadbeef01 10:44:04.483 -> pipe 0 (closed) bound = 0xdeadbeef01 10:44:04.483 -> pipe 1 ( open ) bound = 0x1234567801 10:44:04.520 -> pipe 2 (closed) bound = 0xc3 10:44:04.520 -> pipe 3 (closed) bound = 0xc4 10:44:04.520 -> pipe 4 (closed) bound = 0xc5 10:44:04.520 -> pipe 5 (closed) bound = 0xc6 10:44:04.520 -> I: 10:44:04.520 -> 10:44:04.520 -> ---------------------------------------- 10:44:04.520 -> I: Welcome to AHOY! 10:44:04.520 -> I: 10:44:04.520 -> point your browser to http://192.168.10.229 10:44:04.520 -> I: to configure your device 10:44:04.520 -> I: ---------------------------------------- 10:44:04.520 -> 10:44:10.573 -> I: [NTP]: 2022-06-30 10:44:04 Auf der Website kommt die Fehlermeldung …Receive failed… Inverter 1 not (correctly) configured Inverter 2 not (correctly) configured Kann mir jemand sagen, ob meine ESP-Hardware schon korrekt funktioniert und ob der TSUN schon unterstützt wird. Danke. Grüße Claus T.
Ich habe mal mir den ganzen Ordner NRF angeschaut. Zum Thema Limiterung ist mir was aufgefallen und denke es ist für die neue Generation verantwortlich. In der Datei usart_nrf.h (Zeile 428) gibt es eine Abfrage ob es sich um eine DTU3PRO handelt. Ist das der Fall, werden weitere Parameter gesetzt. Darunter auch ein "DRM_Limit_Switch; //DRM power limit". Für mich ist das ein Indikator das es ein Flag im System zu setzen ist, das aussagt ob eine Limitierung nun erlaubt sei oder nicht. Dies bezüglich habe in der *.c Datei geschaut und siehe da, in der Funktion (Zeile 1717) eine "UsartNrf_Send_PackSetPowerLimitCommand": Hier zeigt sich im Speicher der DTU abgefragt wird, ob der WR sich in einem gewissen Zustand ist.
1 | if((Dtu3Detail.Property.Zero_Export_Switch == 1) || (Dtu3Detail.Property.DRM_Limit_Switch == 1) || (Dtu3Detail.Property.Phase_Balance_Switch == 1) || (Dtu3Detail.Property.SunSpec_Switch == 1)) |
2 | { |
3 | if(MIMajor[PortNO].Property.Acq_Switch == 0) |
4 | { ... |
Ist dieser 0, dann wird folgender Befehl abgeschickt:
1 | //1000w shutdown Micro-inverse control of 1-to-4 with the last 8 digits of the special control ID less than 0x50000000 |
2 | if((MIMajor[PortNO].Property.Id[0] < 0X50) && ((MIMajor[PortNO].Property.Pre_Id[1] == 0X60) || (MIMajor[PortNO].Property.Pre_Id[1] == 0X61))) |
3 | { |
4 | temp_dat[9] = (u8)(SubCmd >> 8); //5a5a |
5 | temp_dat[10] = (u8)(SubCmd & 0XFF); |
6 | temp_dat[11] = 11; |
7 | // temp = 35*4*10=1400=0x0578; |
8 | temp_dat[12] = 0X05; |
9 | temp_dat[13] = 0X78; |
10 | temp_dat[14] = Get_crc_xor((u8 *)&temp_dat[0], 14); //CRC |
11 | i = ForwardSubstitution((u8 *)&Uart_SendBuffer[1], (u8 *)&temp_dat[0], 15); //forward substitution |
12 | } |
13 | else |
14 | { |
15 | temp_dat[9] = (u8)(CONTROL_OFF_SUB >> 8); //5a5a |
16 | temp_dat[10] = (u8)(CONTROL_OFF_SUB & 0XFF); |
17 | temp_dat[11] = Get_crc_xor((u8 *)&temp_dat[0], 11); //CRC |
18 | i = ForwardSubstitution((u8 *)&Uart_SendBuffer[1], (u8 *)&temp_dat[0], 12); //forward substitution |
19 | } |
Wenn nicht dann:
1 | temp_dat[9] = (u8)(SubCmd >> 8); //5a5a |
2 | temp_dat[10] = (u8)(SubCmd & 0XFF); |
3 | temp_dat[11] = (u8)(MIMajor[PortNO].Property.Power_Limit * 10 / (EVERY_PORT_POWER * (UsartNrf_GetInvterType((u8 *)MIMajor[PortNO].Property.Pre_Id)))); //Power limit percentage |
4 | temp_dat[12] = (u8)(MIMajor[PortNO].Property.Power_Limit >> 8); //High 8-bit power limit |
5 | temp_dat[13] = (u8)(MIMajor[PortNO].Property.Power_Limit & 0x00ff); //Low power limit 8 bits |
6 | temp_dat[14] = Get_crc_xor((u8 *)&temp_dat[0], 14); //CRC |
7 | i = ForwardSubstitution((u8 *)&Uart_SendBuffer[1], (u8 *)&temp_dat[0], 15); //forward substitution |
Interessant ist, wenn alles nicht zutrifft wird folgendes verschickt:
1 | temp_dat[9] = (u8)(SubCmd >> 8); //5a5a |
2 | temp_dat[10] = (u8)(SubCmd & 0XFF); |
3 | temp_dat[11] = (u8)(MIMajor[PortNO].Property.Power_Limit * 10 / (EVERY_PORT_POWER * (UsartNrf_GetInvterType((u8 *)MIMajor[PortNO].Property.Pre_Id)))); //Power limit percentage |
4 | temp_dat[12] = (u8)(MIMajor[PortNO].Property.Power_Limit >> 8); //High 8-bit power limit |
5 | temp_dat[13] = (u8)(MIMajor[PortNO].Property.Power_Limit & 0x00ff); //Low power limit 8 bits |
6 | temp_dat[14] = Get_crc_xor((u8 *)&temp_dat[0], 14); //CRC |
7 | i = ForwardSubstitution((u8 *)&Uart_SendBuffer[1], (u8 *)&temp_dat[0], 15); //forward substitution |
Ich werde mal das ganze weiter anschauen und probieren. EDIT: 5A 5A FF <[Property.Power_Limit * 10 / (300 * (UsartNrf_GetInvterType((u8 *)MIMajor[PortNO].Property.Pre_Id)))]> [H 8-bit P limit] [LP limit 8 bits] CRC
:
Bearbeitet durch User
Stefan T. schrieb: > Das könnte auch eine Ursache sein, probier das doch mal aus bzw. > überprüfe das nochmal. Es gab auch schon Probleme bei vertauschten > Anschlüssen des nRF24L01+ per SPI an den ESP8266, also Verkabelung und > Konfiguration nochmal prüfen. Ich entsinne mich daß Lukas P. die Default > Werte in der v0.4.20 geändert hat, da er damit mehr Erfolg hatte: > https://github.com/grindylow/ahoy/issues/36#issuecomment-1169020584 Vielen herzlichen Dank! Darin befindet sich die Lösung. Jetzt funktioniert. Musste CE und IRQ vertauschen. (also nicht nach dem Schaltbild, das auf GitHub ist!) Gleichzeitiger Betrieb mit einer DTU Pro dürfte kein größeres Problem darstellen. Jetzt kämpfe ich nur noch mit Wlan Problemen. Bei mehr als 3-4 Meter Entfernung von Wlan Router, bricht die Verbindung in unregelmäßigen Abständen ab (meist aber schon nach 4-5 Sekunden). Habe schon verschiedene Netzteile und Kabel getestet und mit Kondensatoren experimentiert. Werde jedenfalls noch weiter testen.
Thomas B. schrieb: > Hallo Günter, > Woran scheiterst du da? Was ist die Fehlermeldung? Was passiert oder was > passiert nicht? Danke für die Rückmeldung. Vorweg: Ich bin "kein Programmierer". Bekomme die Arduino IDE (gerade so) zum Laufen. PC mit Windows 10 Pro 21H2 Installation von Visual Studio Code und der PlatformIO Extension innerhalb Visual Studio Code problemlos, Source Code als zip-Datei heruntergeladen, entpackt und platformio.ini geöffnet, upload_port und monitor_port angepasst. Dann "PlatformIO: Upload" angeklickt - danach kamen die Fehlermeldungen, s. Anhänge. Die Zahlen sollen die zeitliche Reihenfolge widerspiegeln. Gemäß Fehlermeldung in VSC_2.txt habe ich dann "git GUI Clients 2.37.0 für Windows" heruntergeladen und installiert. Weiter als zur Fehlermeldung "VSC_3.txt" bin ich dann nicht gekommen. Gruß Günter
Günter H. schrieb: > Gemäß Fehlermeldung in VSC_2.txt habe ich dann "git GUI Clients 2.37.0 > für Windows" heruntergeladen und installiert. Weiter als zur > Fehlermeldung "VSC_3.txt" bin ich dann nicht gekommen. Hallo Günter, du bist dann in das gleiche Problem gelaufen wie hier: https://github.com/tbnobody/OpenDTU/issues/3 Ich werde heute Abend noch eine Ausnahme implementieren, damit man den Source auch bauen kann wenn man ihn nicht via git clone sondern via ZIP heruntergeladen hat.
Kleine parallel Frage, was haltet Ihr davon das ganze auf Discord umzuleiten? Da hier auch über andere Themen gesprochen werden die für das Projekt relevant sind, würde ich vorschlagen statt ein seperaten Thread aufzumachen, hier das auf Discord umzuleiten. Oder sollen wir hier bleiben? Nur eine Idee. :)
Claus T. schrieb: > Hallo, > inzwischen habe ich die ESP8266 Variante zusammengebaut und erfolgreich > mit der Arduino-Umgebung die Version 0.4.20 installiert, WLAN > konfiguriert und die Seriennummer meines TSUN TSOL-M800 eingetragen. > Aus den Forumsbeiträgen schließe ich, dass die SW zur Zeit nur für die > HM-Modelle funktioniert, allerdings war auch schon eine positive Meldung > für den TSUN dabei? > Jetzt bin ich mir nicht sicher, ob es an der Software liegt, oder an > meiner ESP-Verkabelung. > Muss man für die WR-Hardware in der SW vor dem compilieren noch was > ändern, oder wird die WR-Hardware anhand der Seriennummer erkannt. > Um sicherzustellen, das meine ESP-Bastelei korrekt funktioniert, hier > der Auszug der serial-Konsole: > Kann mir jemand sagen, ob meine ESP-Hardware schon korrekt funktioniert > und ob der TSUN schon unterstützt wird. > Danke. > Grüße > Claus T. Hallo Claus, ich bin der mit dem TSOL-M800 (MI-700 Klon). Es gibt noch MI-1500 und 1200, die etwas andere Abfragen starten. Meine Version ist nicht annähernd lauffähig, teilweise instabil und eher unkomminikativ, allerdings ist deine Verkabelung ect. soweit ok. Die älteren MI werden noch nicht unterstützt, ist allerdings in der Mache. Bitte hab etwas Geduld. Ich schaue mal, dass ich meine Version zu github hochlade, wenn sie etwas besser läuft. Aktuell modifiziere ich noch dran. Ggf. kann Daniel R. oder Ziyat eine Testversion für den MI auf dem D1 Mini bereitstellen, die besser anzupassen ist. Wie gesagt, etwas Geduld :)
Daniel R. schrieb: > Kleine parallel Frage, was haltet Ihr davon das ganze auf Discord > umzuleiten? > > Da hier auch über andere Themen gesprochen werden die für das Projekt > relevant sind, würde ich vorschlagen statt ein seperaten Thread > aufzumachen, hier das auf Discord umzuleiten. Oder sollen wir hier > bleiben? > > Nur eine Idee. :) Moin, wenn du einen Einladungslink zu einem Server hast, komme ich gerne dazu :) lg
Discord Link habe ich via PM raus geschickt. :)
Hallo Daniel, danke für die Info, schön zu hören, dass meine HW funktioniert, dann bleibe ich weiter geduldig :-) Mein TSUN TSOL-M800 hat übrigens eine Seriennummer 11417…, hat deiner nicht mit 1041… begonnen? Falls ich irgendwie unterstützen kann, einen ESP32 und nen RaspberryPi hab ich auch noch hier herumliegen, müsste nur nochmal den Lötkolben anschmeißen. Grüße Claus T.
Claus T. schrieb: > Mein TSUN TSOL-M800 hat übrigens eine Seriennummer 11417…, hat deiner > nicht mit 1041… begonnen? Hmmmm 1141.... würde eher für einen 2-Kanal Inverter der HM Reihe sprechen. Nicht das TSUN hier die Nummernkreise noch komplett anders belegt?
Josef J. schrieb: > Gleichzeitiger Betrieb mit einer DTU Pro dürfte kein größeres Problem > darstellen. > Doch, weil deine DTU-Pro dauernd den WR abfragt, sendet der WR antworten zu DTU-Pro. Wenn du in deinem esp-ahoy die gleiche Adresse hast wie die DTU-Pro, wirst du nie wissen ob das esp-ahoy den WR abfragt, bzw. das Senden erfolgreich ist. Du bekommst die WR Antworten zu DTU-Pro gratis mit.
Habe im usart-code was interessantes gefunden. Kann jemand entschlüsseln was das seien könnte? //u8 Uart_SendBuffer1[] = {0x7e, 0x15, 0x50, 0x80, 0x55, 0x56, 0x50, 0x80, 0x55, 0x56, 0x80, 0x02, 0x00, 0x5E, 0x04, 0x7D, 0x5E, 0x2A, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x5B, 0x10, 0xD2, 0x7f}; //u8 Uart_SendBuffer1[] = {0x7e,0x15,0x50,0x80,0x55,0x55,0x50,0x80,0x55,0x55,0x80,0x12,0x00,0x00,0 x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x13,0xb9,0x2d,0x7 f};
Daniel R. schrieb: > Ich habe mal mir den ganzen Ordner NRF angeschaut. Zum Thema Limiterung > ist mir was aufgefallen und denke es ist für die neue Generation > verantwortlich. In der Datei usart_nrf.h (Zeile 428) gibt es eine > Abfrage ob es sich um eine DTU3PRO handelt. > Ist das der Fall, werden weitere Parameter gesetzt. Darunter auch ein > "DRM_Limit_Switch; //DRM power limit". > Eigenlich alles steht im RF_communication_protocol-V6.5.xlsx. Es gibt folg Limitierungen in der Praxis: - zero export: prozentual oder absolut Wert der Nenneistung, gesteuert in Verbindung mit einem Modbus Smart-Meter - Fest limiterte WR: prozentual oder absolut Wert der Nenneistung, eingegeben im smiles-cloud -DRM(Demand Response Mode): der WR wird vom Gridanbieter kontrolliert off/0%/50%/no limit.z.B in Australien, in der EU weiss nicht. Es wird über die DTU-Pro, mit RS485(Modbus oder Sunspec) oder mit einem DRM-Port direkt kommuniziert.
Thomas B. schrieb: > Claus T. schrieb: >> Mein TSUN TSOL-M800 hat übrigens eine Seriennummer 11417…, hat deiner >> nicht mit 1041… begonnen? > > Hmmmm 1141.... würde eher für einen 2-Kanal Inverter der HM Reihe > sprechen. Nicht das TSUN hier die Nummernkreise noch komplett anders > belegt? Nachbar hat auch den TSOL-M800 und die Seriennummer geht auch mit 1141 los und monitore das schon eine ganze Weile.
Claus T. schrieb: > Hallo Daniel, > danke für die Info, schön zu hören, dass meine HW funktioniert, dann > bleibe ich weiter geduldig :-) > Mein TSUN TSOL-M800 hat übrigens eine Seriennummer 11417…, hat deiner > nicht mit 1041… begonnen? > Falls ich irgendwie unterstützen kann, einen ESP32 und nen RaspberryPi > hab ich auch noch hier herumliegen, müsste nur nochmal den Lötkolben > anschmeißen. > Grüße > Claus T. Sehr interessant. Meiner hat mit 1041 begonnen, ja. Hast du 1 oder 2 Inverter laufen? Falls 2, probier mal nur einen einzutragen. Meine Version für den D1 mini ist soweit lauffähig, nicht schön aber es bringt was raus. Ich lade das nachher auf Github, wenn ich rausbekommen habe, wie das geht. Mit einem ESP32 kannst du von Thomas B. das OpenDTU probieren. https://github.com/tbnobody/OpenDTU Allerdings ist es auch bisher nur für die HM-Serie. lg
Richard K. schrieb: > Thomas B. schrieb: >> Claus T. schrieb: >>> Mein TSUN TSOL-M800 hat übrigens eine Seriennummer 11417…, hat deiner >>> nicht mit 1041… begonnen? >> >> Hmmmm 1141.... würde eher für einen 2-Kanal Inverter der HM Reihe >> sprechen. Nicht das TSUN hier die Nummernkreise noch komplett anders >> belegt? > > Nachbar hat auch den TSOL-M800 und die Seriennummer geht auch mit 1141 > los und monitore das schon eine ganze Weile. Was hast du da als Monitoring laufen? Ist es wirklich ein TSOL oder ein umgelabelter HM-Serie? Ich trau den Chinesen alles zu ;)
Thomas B. schrieb: > Hallo Günter, > > du bist dann in das gleiche Problem gelaufen wie hier: > https://github.com/tbnobody/OpenDTU/issues/3 > > Ich werde heute Abend noch eine Ausnahme implementieren, damit man den > Source auch bauen kann wenn man ihn nicht via git clone sondern via ZIP > heruntergeladen hat. Hallo Thomas, nach deinem Hinweis konnte ich den git clone herunterladen - frage bitte nicht, wie das letztlich gelungen ist. Wie auch immer: Das System arbeitet perfekt (HM600), über die Stabilität kann ich naturgemäß noch keine Angaben machen.
Hallo Daniel, Daniel M. schrieb: > Sehr interessant. Meiner hat mit 1041 begonnen, ja. > Hast du 1 oder 2 Inverter laufen? Falls 2, probier mal nur einen > einzutragen. Ich habe am meinem TSOL-M800 an jedem der beiden MPPT-Eingängen ein 370Wp Modul angeschlossen, also beide Inverter laufen. So habe ich sie auch in der ahoy-SW eingetragen, bei Inverter Inverter 0 AddressNameMax Module Power (Wp) 440 440 Module Name CS3L-370 CS3L-370 Inverter 1 Alles weitere leer. Und jetzt noch getestet, die beiden rechten Felder gelöscht. AddressNameMax Module Power (Wp) 440 0 Module Name CS3L-370 Bringt aber auch nix, wobei die Rechte Module Power wird automatisch 0. > > Meine Version für den D1 mini ist soweit lauffähig, nicht schön aber es > bringt was raus. > > Ich lade das nachher auf Github, wenn ich rausbekommen habe, wie das > geht. Gut, dann kann ich die testen. > > Mit einem ESP32 kannst du von Thomas B. das OpenDTU probieren. > https://github.com/tbnobody/OpenDTU > Allerdings ist es auch bisher nur für die HM-Serie. Und dafür muss ich VisualStudio mit PlatformIO installieren, was ich schon mal für ein anderes Projekt probiert hatte und gescheitert bin. Ist aber ein Grund für einen neuen Versuch :-) Die Art des WR wird bei ahoy über die Seriennummer erkannt?
Claus T. schrieb: > Ist aber ein Grund für einen neuen Versuch :-) Habe es auch in meiner Readme dokumentiert. Im optimalfall sind es nur ein paar Klicks um das zu Compilieren und zu übertragen (also incl. VS Code installieren und die PlatformIO Extension zu laden) Claus T. schrieb: > Die Art des WR wird bei ahoy über die Seriennummer erkannt? Genau. Wie in allen anderen Implementierungen aktuell auch. Die Seriennummer --> Modell (bzw. Telegram Typ) Zuordnung war hier recht eindeutig (siehe https://github.com/grindylow/ahoy/blob/main/doc/Hoymiles-SerialNumbers.xlsx)
Holger S. schrieb: > Auf der Suche nach der Reboot Ursache habe ich meine kompilierte 6x > Inverter .bin zum testen auf einen NodeMCU Amica den ich hier noch > rumliegen hatte geflasht. Damit wollte ich ausschliessen das es an den > China Wemos Clones liegt. > > Leider bekomme ich damit auch keine mehrstündigen Uptimes hin. > Eigentlich ja nicht schlimm, da die Daten ja nicht verloren gehen. Aber > irgendwie muß man das doch sauber zum laufen bekommen. > > Läuft das bei euch über Tage ohne Reboot ??? Also ich habe jetzt alle Version ausprobiert. Keine läuft bei mir länger als einen Tag. Danach ist der Wemos nicht mehr zu erreichen und liefert auch keine Daten mehr. Hilft nur noch ein reboot...
Hans W. schrieb: > Also ich habe jetzt alle Version ausprobiert. Keine läuft bei mir länger > als einen Tag. Danach ist der Wemos nicht mehr zu erreichen und liefert > auch keine Daten mehr. Hilft nur noch ein reboot... Betreibe einen NodeMCU mit rf-Modul ohne Cap mit ahoy an meinem HM-800 seit mittlerweile > 3 Wochen ohne Reboot. Großartige Arbeit übrigens @ Dev's!
Daniel M. schrieb: >> Nachbar hat auch den TSOL-M800 und die Seriennummer geht auch mit 1141 >> los und monitore das schon eine ganze Weile. > > Was hast du da als Monitoring laufen? Ist es wirklich ein TSOL oder ein > umgelabelter HM-Serie? > Ich trau den Chinesen alles zu ;) Ja da steht wirklich TSUN TSOL-M800 drauf, und die 1141 passt auch zu dem verhalten. Hat 2 Module mit 370W dran und er ist täglich bei genau 612W scheinbar begrenzt. Hab die Version 0.4.19 am laufen. Für alle die reboots haben, stellt mal das Intervall von 5 sekunden einfach höher, seit ich 20 sekunden eingestellt habe bin ich schon bei 5 Tagen Laufzeit. Das Retry hab ich auch auf 1 stehen. Vielleicht hängt es damit zusammen.
:
Bearbeitet durch User
> Ja da steht wirklich TSUN TSOL-M800 drauf, und die 1141 passt auch zu > dem verhalten. Hat 2 Module mit 370W dran und er ist täglich bei genau > 612W scheinbar begrenzt. > Hab die Version 0.4.19 am laufen. Laut Datenblatt hat es eine Spitzenwirkungsgrad des Wechselrichters von etwa 96,7%. Ich glaub meine Rechnung ist falsch aber wenn ich das ganze Überschlage, sollte etwa folgendes raus kommen: 370W*2= 740W (740W/100) * 96,7 = 715,58WAC ? Für mich heißt es das lt. Rechnung 84,42W fehlen und nach deinen Angaben sogar 188W fehlen. Wenn wir noch bei beiden ca. 20-50W mal für Toleranz abziehen (pi*Daume) dann fehlen bei dir trotzdem gute 130W. Hmm, eventuell wurde hier falsche Firmware oder wie du gesagt hast schon vorab begrenzt. - Keine Ahnung... :/ > Für alle die reboots haben, stellt mal das Intervall von 5 sekunden > einfach höher, seit ich 20 sekunden eingestellt habe bin ich schon bei 5 > Tagen Laufzeit. Das Retry hab ich auch auf 1 stehen. Vielleicht hängt es > damit zusammen. Das sollte man eventuell mal sich merken/Anpinnen. Glaube das hatte bisher keiner im Verdacht? :)
Ja der Wechselrichter ist lt. meines Nachbarns als 600W Begrenzt gekauft worden. Und das tut der auch brav. Ich habe das beim Aufzeichnen auch so festgestellt. Ob dieser das jetzt auf Einspeiseleistung macht oder auf Panelleistung kann man so nicht sagen, denn ich sehe eine harte Begrenzung bei beidem. Im Anhang sieht man das an dem aufgezeichneten Tag immer wieder mal die Sonne weg war wegen einzelnen Wolken, dann ist ja das Panel kühler und wenn die volle Bestrahlung kommt dann liefern die Panels auch mehr Leistung. Und da sieht man ganz deutlich das die Leistung gedeckelt ist. Und ich würde behaupten das diese Serie evtl. auch in der Begrenzung regelbar ist, oder es ist in der Firmware schon so begrenzt.
Hallo zusammen Über die Suche im WWW bin ich auf diesen Thread gestossen. Ich bin überrascht wieviele Leute es doch gibt, die sich gegen ein "Fremdüberwachungscloud" gibt und wieviel Aufwand und Arbeit da reingesteckt wird. Vielen Dank dafür. Seit kurzem läuft bei mir auch ein HM-600 mit einem Stick DTU, den ich aber nur leihweise habe. Wenn ich das ganze hier richtig verstanden habe, gibt es hier 3 Varianten? Welche Variante ist die mir der ich am sichersten die Daten in den Iobroker bringe? Ich bin kein Softwaremensch, ein ESP oder Arduino flashen geht, aber sobald es um komplexe Software geht weiss ich nicht mehr weiter. Darum die Frage. Gruss Andi
Richard K. schrieb: > Ja der Wechselrichter ist lt. meines Nachbarns als 600W Begrenzt gekauft > worden. An sich kann man die alle regeln, da schon festgestellt wurde das TSUN eine kopie von Hoymiles ist. :) Da an sich Zero-Export funktion auch noch möglich ist müssen die sich regeln lassen können. Ich würde sagen wenn HM zu regeln geht, dann kann man denn auch weiter hoch treiben. ;) @Andi: An sich kommt alles drauf an. Wenn du bereits ein Raspi hast und der 24/7 läuft würde ich denn nutzen. Wenn du aber ein ESP8266/32 in der Schublade hast, kann man denn auch gut nutzen. Bei allen jedoch ist ein NRF24L01+ nötig. Sollte aber alles auf Github stehen: https://github.com/grindylow/ahoy/ PS: Du kannst bei allen via MQTT auf iobroker dann legen. ;)
:
Bearbeitet durch User
Hallo Daniel Danke für die Hinweise. Mein Problem besteht darin, dass mein Englisch sehr schlecht ist und sich leider nicht immer alles sinnvoll übersetzen lässt. Als Controller liegt alles bei mir rum, Rpi, ESP8266 und ESP32 als Wemos D1 mini. Dann organisiere ich mir mal den NRF... und beginne mal zu testen. Die ESP Varianten sind mir sympatisch, den die brauchen dann keine Software Support mehr wenn es mal läuft. Rpi ist da halt etwas aufwändiger. Mein Iobroker läuft als Multihost auch auf Rpi CPU. Aber eben im Keller und dort geht die DTU eben nicht. Gruss Andi
Ist zwar Off-Topic, aber du könntest ja dann einfach ein ESP nehmen und das irgendwo in der Mitte zwischen WR und deinem Router einspannen. ;)
Wie meinst du "einspannen"? Als ich denke mir das ich einen ESP nehme und denn einfach an Stelle der DTU verwenden kann?
Einspannen, dazwischen schalten, in dein Netzwerk joinen lassen... :D Richtig, der ESP emuliert einfach die DTU.
Zuerst einmal: Vielen Dank für eure Arbeit! Ich habe mir auch vom Makershop einen NRF24L01+ PA und einen Wemos D1 Mini geholt, geflashed und angeschlossen. Aber er empfängt leider keine Daten vom WR. Ich habe das PinOut zweimal geprüft - auch IRQ/CE. Muss ich den WR selber noch überreden, dass er sendet? Habe ich etwas vergessen in der Firmware zu aktivieren (Muss dort Channel Hopping an oder aus sein?) Gibt es irgendwo eine Anleitung zum systematischen Debugging, z.B. ob das NF24-Modul überhaupt antwortet bzw. betriebsbereit ist? EDIT: HAT sich erledigt. Ich habe keine Ahnung, was sich geändert hat, aber nach dem aktivieren des Loggings, dem richtigen Raten der Baudrate (115200) und dem connecten mit screen läuft es nun.
:
Bearbeitet durch User
Hallo zusammen, ich habe meinen WemosD1Mini nun schon eine ganze Weile mit meinem HM700 am laufen. Soweit funktioniert das auch, jedoch hatte ich jetzt versucht ihn per mqtt mit iobroker zu verbinden aber irgendwie kann er sich nicht mit dem mqtt Server verbinden. Die Anmeldedaten sind jedoch definitiv korrekt aber eine Verbindung schlägt fehlt. Jetzt wollte ich ein OTA Update (aktuelle Version 0.3.3) durchführen und frage mich aber wo ich die dafür benötigten Files finde. Unter https://github.com/grindylow/ahoy konnte ich irgendwie nichts finden. Wäre super wenn ihr mir weiterhelfen könntet, vielleicht sehe ich ja den Wald vor lauter Bäumen nicht. EDIT: Hat sich erledigt. Hab eben gesehen, dass die BIN Files hier im Thread zur Verfügung gestellt werden.
:
Bearbeitet durch User
Daniel R. schrieb: > Richard K. schrieb: >> Ja der Wechselrichter ist lt. meines Nachbarns als 600W Begrenzt gekauft >> worden. > > Ich würde sagen wenn HM zu regeln geht, dann kann man denn auch weiter > hoch treiben. ;) Da bin ich mir nicht sicher, so viel ich informiert bin, die WR's mit einer Begrenzung für div. Laender wie D, wurden fest einprogrammiert. Bin gespannt ob es geht.
Hallo Thomas, Thomas B. schrieb: > Claus T. schrieb: >> Ist aber ein Grund für einen neuen Versuch :-) Hatte heute Zeit VisualStudioCode usw. nochmal zu installieren. Diesmal mit Erfolg. > Habe es auch in meiner Readme dokumentiert. Im optimalfall sind es nur > ein paar Klicks um das zu Compilieren und zu übertragen (also incl. VS > Code installieren und die PlatformIO Extension zu laden) Ich hab’s auf meinem MacBookAir installiert, deine Anleitung hat aber trotzdem sehr gut geholfen. Musste noch Python 3.10 und git installieren. Als serielle Schnittstelle muss man am Mac statt COM4 /dev/cu.usbserial-1410 eingeben. Wobei das vom ESP32-USB-Chip abhängig ist. > > Claus T. schrieb: >> Die Art des WR wird bei ahoy über die Seriennummer erkannt? > Genau. Wie in allen anderen Implementierungen aktuell auch. Die > Seriennummer --> Modell (bzw. Telegram Typ) Zuordnung war hier recht > eindeutig (siehe > https://github.com/grindylow/ahoy/blob/main/doc/Hoymiles-SerialNumbers.xlsx) Nachdem ich unter Settings das Netzwerk und die Seriennummer meines Inverters eingegeben habe, hat es zunächst nicht funktioniert. Hab dann auf der Seriellen Konsole (von Arduino, gibts bestimmt auch bei VisualStudioCode) beobachtet was da so abläuft und wie ich den ESP32 etwas bewegt hatte, kam auch ein „success“. Super! :-) Der WR ist hinter den Solarpannels und natürlich draußen, da reicht der Empfang nicht ganz durch die Hauswand. Jetzt ist der ESP32 draußen mit nem Akku und der Empfang ist gut. Der Wechselrichter wird als HM-600, HM-700, HM-800 erkannt, was anhand der Seriennummer 11417… zu erwarten war, und empfängt sauber alle Daten. Mein TSUN TSOL-M800 ist also kein MI-xxx, sondern ein HM-6/7/800. Die ahoy-Version 0.4.20 auf dem ESP8266 bekommt auch außerhalb des Hauses keine Daten. Dank an alle, die das Projekt schon so weit gebracht haben. lg Claus T.
Oliver F. schrieb: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" ... > Ich habe mir ein ESP32 mit 6 Modulen gebaut. Leider kamen die > erforderlichen NRF Module erst an dem Tag an dem ich in Urlaub gefahren > bin. Hallo Oliver, was ist aus dem ESP32 mit 6 x nRF Modulen denn geworden ? Gibt es da Neuigkeiten ? Viele Grüße Herbert
:
Bearbeitet durch User
Bei mir funktioniert alles wie es soll, auch MQTT. Nur habe ich zwischendurch immer 0 Werte bei allen Werten. Kann man das irgendwie unterbinden?
Also ich habe jetzt die Version 4.19 geflashed aber leider kann er weiterhin keine Verbindung zu mqtt herstellen. Gibt es Broker seitig etwas zu beachten? Benutzername und Passwort habe ich angegeben. Die IP habe ich normal im Format 192.168.42.101 angegeben. Muss beim Topic etwas beachtet werden?
Hallo Silvio, an sich nichts großes. Probiere mal via MQTTExplorer (https://github.com/thomasnordquist/MQTT-Explorer) zu lauschen ob die Daten auch empfangen werden. In den Einstellung bei deinem DTU muss unter MQTT auch passend die Werte eingepflegt werden. Denke mal das hast du auch gemacht.
Ziyat T. schrieb: >> Ich würde sagen wenn HM zu regeln geht, dann kann man denn auch weiter >> hoch treiben. ;) > > Da bin ich mir nicht sicher, so viel ich informiert bin, die WR's mit > einer Begrenzung für div. Laender wie D, wurden fest einprogrammiert. > Bin gespannt ob es geht. Das 600W Limit sollte mit einem neuen "Gridfile" überschrieben werden können. Das allerdings geht nur mit der DTU Pro, wo man (angeblich) die Settings im WR anpassen kann. Soweit ich die Installationsanleitungen verstehe, gibt es da Optionen. In dem Gitee waren auch Hinweise auf dieses "Gridfile", vorwiegend aber für die MI-Serie. Habe heute meinen HM-1500 bekommen und bin gespannt, ob die EU-Version (nicht explizit DE) das Limit auf 600W drin hat. Ahoy-Software hat nach Pintausch auf einem Wemos kurzzeitig funktioniert, ich vermute, hier hats einfach durch die Bastelumgebung zuviel Störzeug, was überlagert. Die Version auf dem ESP32 hatte da (wahrscheinlich wegen der Störfelder) noch nicht geklappt, ich werde aber damit auch testen.
Claus T. schrieb: > Hatte heute Zeit VisualStudioCode usw. nochmal zu installieren. Diesmal > mit Erfolg. Glückwunsch! :) > Nachdem ich unter Settings das Netzwerk und die Seriennummer meines > Inverters eingegeben habe, hat es zunächst nicht funktioniert. Hab dann > auf der Seriellen Konsole (von Arduino, gibts bestimmt auch bei > VisualStudioCode) beobachtet was da so abläuft und wie ich den ESP32 > etwas bewegt hatte, kam auch ein „success“. Super! :-) > > Der WR ist hinter den Solarpannels und natürlich draußen, da reicht der > Empfang nicht ganz durch die Hauswand. > Jetzt ist der ESP32 draußen mit nem Akku und der Empfang ist gut. Also die Nachfolgerversion meines "alten" MI-Klon. Wenn du Daten bekommst, ist das super. > Die ahoy-Version 0.4.20 auf dem ESP8266 bekommt auch außerhalb des > Hauses keine Daten. Probier mal einen Pintausch, CS bleibt auf D8, CE geht auf D3 und IRQ auf D4. Alternativ kannst du auch D8, D2, D1 probieren.
Silvio R. schrieb: > Also ich habe jetzt die Version 4.19 geflashed aber leider kann er > weiterhin keine Verbindung zu mqtt herstellen. > Gibt es Broker seitig etwas zu beachten? > Benutzername und Passwort habe ich angegeben. Die IP habe ich normal im > Format 192.168.42.101 angegeben. > Muss beim Topic etwas beachtet werden? Für die neuere MQTT Version >2.x brauchst du zwingend Username/Passwort, außer du konfigurierst den Server entsprechend um. Sonst ist der Tip mit MQTT.fx oder MQTT Explorer ganz gut zum Schauen. Normal sollte nichts weiter beachtet werden.
Werden die Werte für AC Power eigentlich aufgrund der Werte von DC Power errechnet, oder werden diese vom Wechselrichter direkt übertragen?
bei der HM Serie wird AC Power und die einzelnen DC Power der Eingänge übertragen. Die ESP Version errechnet die Gesamt DC Power und daraus wieder den Wirkungsgrad. Messungen von einigen hier aus dem Forum haben gezeigt, dass die AC Powermessung sehr genau stimmt. Mal eine Frage in die Runde: Wie heiß werden eigentlich eure Wechselrichter? Gibt es eine Overtemperature Abschaltung? Ich habe bei mir schon 73°C gesehen. Das passt auch zu meiner Vorstellung, dass bei ca. 1.1kW und 95.5% Wirkungsgrad ca. 50W in Wärme umgewandelt werden. Man muss dazu sagen, das ich auf zwei Eingängen Parallelschaltungen und damit verbunden hohe Ströme habe.
Lukas P. schrieb: > Mal eine Frage in die Runde: Wie heiß werden eigentlich eure > Wechselrichter? Der Maximalwert in meiner Datenbank beträgt 64,8°C (HM-1500)
Lukas P. schrieb: > bei der HM Serie wird AC Power und die einzelnen DC Power der > Eingänge übertragen. > Die ESP Version errechnet die Gesamt DC Power und daraus wieder den > Wirkungsgrad. > Messungen von einigen hier aus dem Forum haben gezeigt, dass die AC > Powermessung sehr genau stimmt. Vielen Dank. Momentan lese ich noch die Daten via Modbus TCP von der DTU Pro aus. Ich denke, dass dies aber die DC Power sein wird (Laut Doku PV Power). Das muss ich mal vergleichen. Zu den Temperaturen kann ich noch nichts sagen, da ich den WR erst seit einer Woche habe.
Thomas B. schrieb: > Lukas P. schrieb: >> Mal eine Frage in die Runde: Wie heiß werden eigentlich eure >> Wechselrichter? > > Der Maximalwert in meiner Datenbank beträgt 64,8°C (HM-1500) Aussen 38.5C, WR 64.9C
Daniel M. schrieb: > Ziyat T. schrieb: >>> Ich würde sagen wenn HM zu regeln geht, dann kann man denn auch weiter >>> hoch treiben. ;) >> >> Da bin ich mir nicht sicher, so viel ich informiert bin, die WR's mit >> einer Begrenzung für div. Laender wie D, wurden fest einprogrammiert. >> Bin gespannt ob es geht. > > Das 600W Limit sollte mit einem neuen "Gridfile" überschrieben werden > können. Das allerdings geht nur mit der DTU Pro, wo man (angeblich) die > Settings im WR anpassen kann. Das Gridfile hat die Parameter nur fürs Grid, keine Limits, siehe: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Hallo Daniel, Daniel M. schrieb: >> Die ahoy-Version 0.4.20 auf dem ESP8266 bekommt auch außerhalb des >> Hauses keine Daten. > > Probier mal einen Pintausch, CS bleibt auf D8, CE geht auf D3 und IRQ > auf D4. Alternativ kannst du auch D8, D2, D1 probieren. hab mir die config der SW angesehen, dort ist IRQ 2 (D4) und CE 0 (D3) vertauscht angegeben Vergleich der Bilder AhoyMiles_bb.png + AhoyMiles_schem.png im git. Die Bilder zeigen einen WeMos D1 mini, den ich auch verwende. Also 2 Kabel kurz umgelötet, im ahoy-Setup IRQ und CE nochmal kontrolliert bzw. angepasst... und es läuft :-) Nur das tauschen im ahoy-Setup per SW, hatte ich vorher schon getestet, hat nix geholfen. Bei der SW ahoy ESP8266 Version 0.4.20 hab ich nichts geändert. Im ahoy-Setup habe ich jetzt CE = D3(GPIO0) und IRQ = D4(GPIO2) eingestellt. Grüße Claus
Interrupt und ReceiveChannel Hallo, Ich habe von meinem MI-1500 immer wieder keine Daten mehr bekommen, habe den Grund untersucht. - Unbedingt nicht nur auf CH03 hören, mein MI-1500 sendet z.B. heute nichts über CH03. Er sendet heute nur über CH61 und CH75 !! - Wenn ich ohne Interrupt den NRF24 polle, sehe ich mehr Daten So bekomme schön und regelmaessig Daten vom MI-1500
:
Bearbeitet durch User
Ich habe bei meinem HM-1500 schon 79°C gesehen. Das kommt mir auch etwas viel vor. Ist aber unter den Panels auf einem Flachdach.
Ich habe eine HM-1500. Max Temperatur war knapp über 60°C. Hab jetzt ein kleinen 12V Lüfter davor gestellt mit kleinem Solar Panel. Seit dem bin ich bei Max 45°C. Gruß Tom
Hallo Claus, Claus T. schrieb: > hab mir die config der SW angesehen, dort ist IRQ 2 (D4) und CE 0 (D3) > vertauscht angegeben Vergleich der Bilder AhoyMiles_bb.png + > AhoyMiles_schem.png im git. Die Bilder zeigen einen WeMos D1 mini, den > ich auch verwende. Ich muss nochmal drüber schauen, ich habe auch den Typ im Einsatz. > Also 2 Kabel kurz umgelötet, im ahoy-Setup IRQ und CE nochmal > kontrolliert bzw. angepasst... und es läuft :-) Wenns läuft, ist top :) Glückwunsch! > Nur das tauschen im ahoy-Setup per SW, hatte ich vorher schon getestet, > hat nix geholfen. > Bei der SW ahoy ESP8266 Version 0.4.20 hab ich nichts geändert. > Im ahoy-Setup habe ich jetzt CE = D3(GPIO0) und IRQ = D4(GPIO2) > eingestellt. Ich hab das auch noch nicht ganz verstanden, warum das nicht klappt. Ich nutze 2 identische D1 mini, identisch verkabelt und eingerichtet, selbe Position und das NRF Modul genauso ausgerichtet, der eine läuft, der andere nicht.
Ziyat T. schrieb: > Das Gridfile hat die Parameter nur fürs Grid, keine Limits, siehe: > Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" Hallo Ziyat, ich bin nicht sicher, ob für die HM-Serie ggf. weitere Parameter vorgesehen sind. Als die MI-Serie aktuell war, gab es keine Limits in der Form (soweit mir bekannt). Mein HM-1500 (EU-Version) kennt kein 600W Limit. Ahoy auf D1 Mini und Thomas seine Version auf ESP32 laufen perfekt. Mit dem MI-Klon bin ich noch nicht weiter, heute erstmal die 4 Panele mit dem HM aufgestellt. lg Daniel
Wegen getauschten Verbindungen des ESP8266 Code von Lukas P., das hat er ab Versiom 0.4.20 geändert: https://github.com/grindylow/ahoy/issues/36#issuecomment-1169020584 Jetzt gilt als Default: CS = D8(GPIO15) CE = D3(GPIO0) IRQ = D4(GPIO2) Ich muss noch die Fritzing Schematics & die Beschreibung dementsprechend anpassen. Verstehen tue ich’s auch (noch) nicht. Bei mir hat die 30 s Intervallzeit mE viel mehr Erfolg als irgendeine geänderte Belegung. Aber wenn‘s Euch hilft =^D Wir sollten evtl überlegen ob wir den von Ziyat T. vorgeschlagenen Weg: kein IRQ und auf allen Kanälen empfangen und/oder senden auch umsetzen ? Zumindest die Raspberry Pi Variante von Jan-Jonas S. kommt schließlich auch ohne IRQ aus. Vielleicht ist ein gutes Timing wie im uart_nrf.c/.h code des Herstellers besser als ein Interrupthandler der ständig dazwischenkommt/-„funkt“.
HAllo habe teiweise resets ohne ersichtlichem Grund. Kann jemand aus dem Log etwas lesen warum? equesting Inverter SN 114180113742 Transmit 27 | 15 80 11 37 42 78 56 34 12 80 0B 00 62 C1 61 21 00 00 00 05 00 00 00 00 58 2A E6 Received 27 bytes channel 3: 95 80 11 37 42 80 11 37 42 01 00 01 00 0A 00 03 00 00 01 3C 00 41 00 CE 00 00 2E Received 27 bytes channel 3: 95 80 11 37 42 80 11 37 42 01 00 01 00 0A 00 03 00 00 01 3C 00 41 00 CE 00 00 2E Received 27 bytes channel 23: 95 80 11 37 42 80 11 37 42 01 00 01 00 0A 00 03 00 00 01 3C 00 41 00 CE 00 00 2E Received 23 bytes channel 3: 95 80 11 37 42 80 11 37 42 83 00 00 00 08 03 E8 00 FA 00 D2 3E 2D CE Received 23 bytes channel 3: 95 80 11 37 42 80 11 37 42 83 00 00 00 08 03 E8 00 FA 00 D2 3E 2D CE Received 23 bytes channel 23: 95 80 11 37 42 80 11 37 42 83 00 00 00 08 03 E8 00 FA 00 D2 3E 2D CE Error while retrieving data: Frame 2 missing: Request Retransmit Transmit 11 | 15 80 11 37 42 78 56 34 12 82 7B Received 27 bytes channel 3: 95 80 11 37 42 80 11 37 42 02 00 90 00 00 1B 1E 00 00 00 28 09 39 13 89 00 C4 44 Received 27 bytes channel 3: 95 80 11 37 42 80 11 37 42 02 00 90 00 00 1B 1E 00 00 00 28 09 39 13 89 00 C4 44 Received 27 bytes channel 3: 95 80 11 37 42 80 11 37 42 02 00 90 00 00 1B 1E 00 00 00 28 09 39 13 89 00 C4 44 Payload (42): 00 01 00 0A 00 03 00 00 01 3C 00 41 00 CE 00 00 00 90 00 00 1B 1E 00 00 00 28 09 39 13 89 00 C4 00 00 00 08 03 E8 00 FA 00 D2 --------------- CUT HERE FOR EXCEPTION DECODER --------------- Exception (3): epc1=0x401007a5 epc2=0x00000000 epc3=0x00000000 excvaddr=0x40031dd9 depc=0x00000000 >>>stack>>> ctx: sys sp: 3fffec20 end: 3fffffb0 offset: 0190 3fffedb0: 00000319 00000319 3ffe85dc 401009d3 3fffedc0: 00000319 00000319 3ffe85dc 401009d3 3fffedd0: 3fff1d1c 00000020 3fff1d1c 3fff1d1c 3fffede0: 00000000 00000020 3fff1d1c 40100bb2 3fffedf0: 40104533 00000000 00000000 40100534 3fffee00: 0000011c 00000020 3fff3b3c 402253f8 3fffee10: 401033fc 3fff1d1c 3fff1d1c 4021d339 3fffee20: 000007d3 000007d3 3ffe85dc 4021de40 3fffee30: 00000000 2c9f0300 4000050c 4021e4c7 3fffee40: 3fff1d1c 00000020 3fff42ec 40100bb2 3fffee50: 0055f4e5 cc21a274 00000000 40100534 3fffee60: 3fff1d1c 3fff0400 00000006 3fff03fc 3fffee70: 3fff1d1c 3fff0400 00000005 4021e530 3fffee80: 3fff1d1c 3fff0400 00000005 40226f47 3fffee90: 00000000 00000000 4bc6a7f0 402253d1 3fffeea0: 00000019 00000000 401002dd 00000000 3fffeeb0: 3fff0000 00000152 00000020 3ffeffb0 3fffeec0: 3fff0230 3fff430a 3fff42ec 402246e9 3fffeed0: 00000014 3ffeffb0 3ffe85dc 401009d3 3fffeee0: 00000000 3fff058c 3ffeda50 3fff1c8c 3fffeef0: 3fffdc80 00000020 3fff35e4 3fff1c8c 3fffef00: 3ffeffb0 00000008 3fff42ec 4021d209 3fffef10: 3fffdc80 3fff0834 3fff35e4 4021d008 3fffef20: 4024558d 3fff0834 3fff35e4 4024559f 3fffef30: 3fff42fc 3fff42ec 00000000 3ffe85d8 3fffef40: 40241ffb 00000000 3fff35e4 40246873 3fffef50: 40000f49 3fffdab0 3fffdab0 40000f49 3fffef60: 40000e19 000593d1 00000000 00000005 3fffef70: 60000600 aa55aa55 000000f7 40105539 3fffef80: 4010553f 00000000 00000005 40100b8c 3fffef90: 4010000d 56bde7c1 000593d1 401000ac 3fffefa0: 00000000 3fffef3c 00000000 3ffffe58 3fffefb0: 3fffffc0 00000000 00000000 feefeffe 3fffefc0: feefeffe feefeffe feefeffe feefeffe 3fffefd0: feefeffe feefeffe feefeffe feefeffe 3fffefe0: feefeffe feefeffe feefeffe feefeffe 3fffeff0: feefeffe feefeffe feefeffe feefeffe 3ffff000: feefeffe feefeffe feefeffe feefeffe 3ffff010: feefeffe feefeffe feefeffe feefeffe 3ffff020: feefeffe feefeffe feefeffe feefeffe 3ffff030: feefeffe feefeffe feefeffe feefeffe 3ffff040: feefeffe feefeffe feefeffe feefeffe 3ffff050: feefeffe feefeffe feefeffe feefeffe 3ffff060: feefeffe feefeffe feefeffe feefeffe 3ffff070: feefeffe feefeffe feefeffe feefeffe 3ffff080: feefeffe feefeffe feefeffe feefeffe 3ffff090: feefeffe feefeffe feefeffe feefeffe 3ffff0a0: feefeffe feefeffe feefeffe feefeffe 3ffff0b0: feefeffe feefeffe feefeffe feefeffe 3ffff0c0: feefeffe feefeffe feefeffe feefeffe 3ffff0d0: feefeffe feefeffe feefeffe feefeffe 3ffff0e0: feefeffe feefeffe feefeffe feefeffe 3ffff0f0: feefeffe feefeffe feefeffe feefeffe 3ffff100: feefeffe feefeffe feefeffe feefeffe 3ffff110: feefeffe feefeffe feefeffe feefeffe 3ffff120: feefeffe feefeffe feefeffe feefeffe 3ffff130: feefeffe feefeffe feefeffe feefeffe 3ffff140: feefeffe feefeffe feefeffe feefeffe 3ffff150: feefeffe feefeffe feefeffe feefeffe 3ffff160: feefeffe feefeffe feefeffe feefeffe 3ffff170: feefeffe feefeffe feefeffe feefeffe 3ffff180: feefeffe feefeffe feefeffe feefeffe 3ffff190: feefeffe feefeffe feefeffe feefeffe 3ffff1a0: feefeffe feefeffe feefeffe feefeffe 3ffff1b0: feefeffe feefeffe feefeffe feefeffe 3ffff1c0: feefeffe feefeffe feefeffe feefeffe 3ffff1d0: feefeffe feefeffe feefeffe feefeffe 3ffff1e0: feefeffe feefeffe feefeffe feefeffe 3ffff1f0: feefeffe feefeffe feefeffe feefeffe 3ffff200: feefeffe feefeffe feefeffe feefeffe 3ffff210: feefeffe feefeffe feefeffe feefeffe 3ffff220: feefeffe feefeffe feefeffe feefeffe 3ffff230: feefeffe feefeffe feefeffe feefeffe 3ffff240: feefeffe feefeffe feefeffe feefeffe 3ffff250: feefeffe feefeffe feefeffe feefeffe 3ffff260: feefeffe feefeffe feefeffe feefeffe 3ffff270: feefeffe feefeffe feefeffe feefeffe 3ffff280: feefeffe feefeffe feefeffe feefeffe 3ffff290: feefeffe feefeffe feefeffe feefeffe 3ffff2a0: feefeffe feefeffe feefeffe feefeffe 3ffff2b0: feefeffe feefeffe feefeffe feefeffe 3ffff2c0: feefeffe feefeffe feefeffe feefeffe 3ffff2d0: feefeffe feefeffe feefeffe feefeffe 3ffff2e0: feefeffe feefeffe feefeffe feefeffe 3ffff2f0: feefeffe feefeffe feefeffe feefeffe 3ffff300: feefeffe feefeffe feefeffe feefeffe 3ffff310: feefeffe feefeffe feefeffe feefeffe 3ffff320: feefeffe feefeffe feefeffe feefeffe 3ffff330: feefeffe feefeffe feefeffe feefeffe 3ffff340: feefeffe feefeffe feefeffe feefeffe 3ffff350: feefeffe feefeffe feefeffe feefeffe 3ffff360: feefeffe feefeffe feefeffe feefeffe 3ffff370: feefeffe feefeffe feefeffe feefeffe 3ffff380: feefeffe feefeffe feefeffe feefeffe 3ffff390: feefeffe feefeffe feefeffe feefeffe 3ffff3a0: feefeffe feefeffe feefeffe feefeffe 3ffff3b0: feefeffe feefeffe feefeffe feefeffe 3ffff3c0: feefeffe feefeffe feefeffe feefeffe 3ffff3d0: feefeffe feefeffe feefeffe feefeffe 3ffff3e0: feefeffe feefeffe feefeffe feefeffe 3ffff3f0: feefeffe feefeffe feefeffe feefeffe 3ffff400: feefeffe feefeffe feefeffe feefeffe 3ffff410: feefeffe feefeffe feefeffe feefeffe 3ffff420: feefeffe feefeffe feefeffe feefeffe 3ffff430: feefeffe feefeffe feefeffe feefeffe 3ffff440: feefeffe feefeffe feefeffe feefeffe 3ffff450: feefeffe feefeffe feefeffe feefeffe 3ffff460: feefeffe feefeffe feefeffe feefeffe 3ffff470: feefeffe feefeffe feefeffe feefeffe 3ffff480: feefeffe feefeffe feefeffe feefeffe 3ffff490: feefeffe feefeffe feefeffe feefeffe 3ffff4a0: feefeffe feefeffe feefeffe feefeffe 3ffff4b0: feefeffe feefeffe feefeffe feefeffe 3ffff4c0: feefeffe feefeffe feefeffe feefeffe 3ffff4d0: feefeffe feefeffe feefeffe feefeffe 3ffff4e0: feefeffe feefeffe feefeffe feefeffe 3ffff4f0: feefeffe feefeffe feefeffe feefeffe 3ffff500: feefeffe feefeffe feefeffe feefeffe 3ffff510: feefeffe feefeffe feefeffe feefeffe 3ffff520: feefeffe feefeffe feefeffe feefeffe 3ffff530: feefeffe feefeffe feefeffe feefeffe 3ffff540: feefeffe feefeffe feefeffe feefeffe 3ffff550: feefeffe feefeffe feefeffe feefeffe 3ffff560: feefeffe feefeffe feefeffe feefeffe 3ffff570: feefeffe feefeffe feefeffe feefeffe 3ffff580: feefeffe feefeffe feefeffe feefeffe 3ffff590: feefeffe feefeffe feefeffe feefeffe 3ffff5a0: feefeffe feefeffe feefeffe feefeffe 3ffff5b0: feefeffe feefeffe feefeffe feefeffe 3ffff5c0: feefeffe feefeffe feefeffe feefeffe 3ffff5d0: feefeffe feefeffe feefeffe feefeffe 3ffff5e0: feefeffe feefeffe feefeffe feefeffe 3ffff5f0: feefeffe feefeffe feefeffe feefeffe 3ffff600: feefeffe feefeffe feefeffe feefeffe 3ffff610: feefeffe feefeffe feefeffe feefeffe 3ffff620: feefeffe feefeffe feefeffe feefeffe 3ffff630: feefeffe feefeffe feefeffe feefeffe 3ffff640: feefeffe feefeffe feefeffe feefeffe 3ffff650: feefeffe feefeffe feefeffe feefeffe 3ffff660: feefeffe feefeffe feefeffe feefeffe 3ffff670: feefeffe feefeffe feefeffe feefeffe 3ffff680: feefeffe feefeffe feefeffe feefeffe 3ffff690: feefeffe feefeffe feefeffe feefeffe 3ffff6a0: feefeffe feefeffe feefeffe feefeffe 3ffff6b0: feefeffe feefeffe feefeffe feefeffe 3ffff6c0: feefeffe feefeffe feefeffe feefeffe 3ffff6d0: feefeffe feefeffe feefeffe feefeffe 3ffff6e0: feefeffe feefeffe feefeffe feefeffe 3ffff6f0: feefeffe feefeffe feefeffe feefeffe 3ffff700: feefeffe feefeffe feefeffe feefeffe 3ffff710: feefeffe feefeffe feefeffe feefeffe 3ffff720: feefeffe feefeffe feefeffe feefeffe 3ffff730: feefeffe feefeffe feefeffe feefeffe 3ffff740: feefeffe feefeffe feefeffe feefeffe 3ffff750: feefeffe feefeffe feefeffe feefeffe 3ffff760: feefeffe feefeffe feefeffe feefeffe 3ffff770: feefeffe feefeffe feefeffe feefeffe 3ffff780: feefeffe feefeffe feefeffe feefeffe 3ffff790: feefeffe feefeffe feefeffe feefeffe 3ffff7a0: feefeffe feefeffe feefeffe feefeffe 3ffff7b0: feefeffe feefeffe feefeffe feefeffe 3ffff7c0: feefeffe feefeffe feefeffe feefeffe 3ffff7d0: feefeffe feefeffe feefeffe feefeffe 3ffff7e0: feefeffe feefeffe feefeffe feefeffe 3ffff7f0: feefeffe feefeffe feefeffe feefeffe 3ffff800: feefeffe 00000000 feefeffe 000000f9 3ffff810: 00000064 00000001 40105385 3ffee228 3ffff820: 00000002 00000000 00000020 401001c8 3ffff830: 401025d1 00000001 00000002 401021a0 3ffff840: 3ffea062 4010541f 3ffed780 000000fe 3ffff850: 00000002 00000000 00000020 401001c8 3ffff860: 00000002 00000000 00000020 401001c8 3ffff870: 401025d1 4010541f 00000002 401021a0 3ffff880: 3ffea062 4010541f 3ffed780 00040000 3ffff890: 00000001 401045fa 3ffee228 401001c8 3ffff8a0: 40104a6b 40105437 3ffeda50 401001c8 3ffff8b0: 40104533 00000000 00000002 000000fe 3ffff8c0: 40104533 00000029 00000002 00040000 3ffff8d0: 00002200 00000000 00000000 000000ff 3ffff8e0: 00000005 00000000 00000020 401001c8 3ffff8f0: 3ffee1b0 00000000 00000005 401021a0 3ffff900: 3ffea065 40105437 3ffedaf0 401001c8 3ffff910: 40102d2b 3ffedaf0 00000002 401021a0 3ffff920: 00000000 00000000 0000001f 401001c8 3ffff930: 3ffea910 00000000 3fffc228 40105cd1 3ffff940: 4000050c 2c9f0300 4000050c 3fffc278 3ffff950: 401030e4 3fffc200 00000022 ffffffff 3ffff960: 4022fdd4 00000030 00000000 ffffffff 3ffff970: 4022b896 3fff1a48 00000001 40000000 3ffff980: 00000000 bfffffff 00080240 c00c3004 3ffff990: 3ffecf00 000c3000 ff000fff 3ffeeb50 3ffff9a0: 3fff058c 00000001 3fff4f8c 00000030 3ffff9b0: 40216535 00000000 00000003 00000000 3ffff9c0: 00000000 3ffffc50 00000002 3ffffba0 3ffff9d0: 00000002 00000000 00000020 401001c8 3ffff9e0: 00000002 00000000 0000000a 00000000 3ffff9f0: 00000002 00000000 40243157 00000000 3ffffa00: ffffffff 00000000 3ffea1b1 00000000 3ffffa10: 402431a6 00000000 3fff058c 000000fa 3ffffa20: 0000006c 00000001 40105385 3ffee228 3ffffa30: 3ffee1b0 00000005 00000002 401021a0 3ffffa40: 3ffea062 40242263 3ffed758 3fff4f8c 3ffffa50: 40104f6a 3ffee228 3ffeeb50 3fff058c 3ffffa60: 00000000 401048b9 3ffee228 3ffed758 3ffffa70: 3fff4fc2 40105a7b 3fff1a48 3ffeff98 3ffffa80: 40105081 3ffee228 00000008 00040000 3ffffa90: 53002200 4021cc0d 3fff1a48 3ffeff98 3ffffaa0: 4010513d 00080000 00000002 3ffffbc0 3ffffab0: 40103412 00000000 3ffffb10 3ffeffb0 3ffffac0: 3ffeffb0 00000000 3fff4f8c 4021ce3b 3ffffad0: 3ffeffe8 2c9f0300 4000050c 3fffc278 3ffffae0: 401030e4 3fffc200 00000022 00040000 3ffffaf0: 40000656 00000030 00000010 ffffffff 3ffffb00: 401002dd 00000000 00000000 4bc6a7f0 3ffffb10: 00000000 282a097f 3fff08e8 00000000 3ffffb20: 00004c35 3fffc6fc 47cf097f 00000000 3ffffb30: 002455a3 522d0e56 2a0304d7 00000030 3ffffb40: 4020a156 00000030 00000010 ffffffff 3ffffb50: 4020a152 00000000 00418937 00000000 3ffffb60: 00000000 3fff1e04 00000020 40100bdc 3ffffb70: 00000000 3ffe9f94 00000000 40100510 3ffffb80: 00000000 00000218 00000020 402253d1 3ffffb90: 00000006 3fff03c0 00000274 4021d2e4 3ffffba0: 00000452 00000010 3ffffc6c 4021d314 3ffffbb0: 3ffeffb0 3fff1e04 00000000 4021ff43 3ffffbc0: 00000000 0057180f 00000000 4020feb4 3ffffbd0: 00000046 7fffffff 3ffffc9c 00000000 3ffffbe0: 00000000 4bc6a7f0 6624dd2f 2a0304ee 3ffffbf0: 00000000 00000000 4bc6a7f0 00000000 3ffffc00: 00000001 3fff4064 401002dd 00000000 3ffffc10: 002455a3 3fff1e08 00000010 00000073 3ffffc20: 007a1200 77de7f91 3ffffd00 00000002 3ffffc30: 00000001 00000000 3fff2004 4020a152 3ffffc40: 00000010 00000010 00000073 3ffffcf0 3ffffc50: 3fff08e8 00000000 00000073 000000ff 3ffffc60: 000000cf 00000001 40105385 3ffee228 3ffffc70: 3ffee1b0 3ffffd14 3ffffc90 4020f5c4 3ffffc80: 04c4b400 77dea726 3fff0900 40202db8 3ffffc90: 40104f6a 00000000 00000010 000000fd 3ffffca0: 000000cf 00000001 40105385 3ffee228 3ffffcb0: 3ffee1b0 00000000 312e312f 3ffffd50 3ffffcc0: 00000005 00000000 00000020 401001c8 3ffffcd0: 401025d1 3ffee228 00000005 401021a0 3ffffce0: 4010432f 00040000 00000000 00040000 3ffffcf0: 00002200 4010432c 00040000 40105cd1 3ffffd00: 3ffee228 40103293 3ffee3fc 40102f08 3ffffd10: 00000005 00000000 00000020 401001c8 3ffffd20: 4000066d 2c9f0300 00000005 401021a0 3ffffd30: 3ffea065 40105437 3ffeda50 401001c8 3ffffd40: 40102d2b 3ffeda50 0000001f 401001c8 3ffffd50: 000000a7 8df3c376 3ffee3fc 40102f08 3ffffd60: 3ffea91c 00000000 00000000 3ffefb94 3ffffd70: 000000a7 8df3c376 401033c2 00000100 3ffffd80: 3ffea91c 7fffffff 00002200 00000001 3ffffd90: 00000001 00004a88 00000000 fffffffe 3ffffda0: 3ffea91c 3fffc6fc 00000001 8df3c376 3ffffdb0: 3ffea8ec 2c9f0300 4000050c 3fffc278 3ffffdc0: 401030e4 3fffc200 00000022 8df35128 3ffffdd0: 401060c2 00000030 00000010 ffffffff 3ffffde0: 4010028a 3ff20a00 3ffea8d8 00000000 3ffffdf0: 00004bc6 00000000 00000000 fffffffe 3ffffe00: 00000000 3fffc6fc 00000000 3ffefb80 3ffffe10: 00000000 3ffef6a0 3ffefb94 00000030 3ffffe20: 00000000 4bc6a7f0 ebc6a7ef 2a049598 3ffffe30: 007a1200 7985a96f 4bc6a700 00000000 3ffffe40: 00000000 00000000 00000001 401001c8 3ffffe50: 00000000 4bc6a7f0 eed91687 2a04959c 3ffffe60: 00000000 00000000 4bc6a7f0 00000000 3ffffe70: 3ffef6a0 3fff08e8 401002dd 00000000 3ffffe80: 002456fd 00000000 00000000 fffffffe 3ffffe90: 00000000 4bc6a7f0 f4bc6a7f 2a0495a3 3ffffea0: 00000000 00000000 4bc6a7f0 00000000 3ffffeb0: 402113ec 40100e60 401002dd 00000000 3ffffec0: 002456fd 00000000 00000000 fffffffe 3ffffed0: ffffffff 3fffc6fc 00000001 3ffefb94 3ffffee0: 3ffef6a0 00000000 3ffefb80 4020464e 3ffffef0: 00000000 3fffdad0 3ffefb94 00000030 3fffff00: 00000000 3fffdad0 3ffefb94 00000030 3fffff10: 54646c65 6c61746f 3ffe8500 401009d3 3fffff20: 00000000 001d001f 00000000 00000000 3fffff30: 000b000f 00000000 00000000 001b001f 3fffff40: 00000000 00000000 001a001f 00000000 3fffff50: 00000000 000b000f 00000000 3ffefb94 3fffff60: 007a1200 7985b2a9 00000000 3fff1314 3fffff70: 00000000 3fff12fc 3fff1310 feefeffe 3fffff80: 00000000 00000000 00000001 401001c8 3fffff90: 3fffdad0 00000000 3ffefb80 401001e9 3fffffa0: feefeffe feefeffe 3ffefb80 40211412 <<<stack<<< --------------- CUT HERE FOR EXCEPTION DECODER --------------- ets Jan 8 2013,rst cause:2, boot mode:(3,6) load 0x4010f000, len 3460, room 16 tail 4 chksum 0xcc load 0x3fff20b8, len 40, room 4 tail 4 chksum 0xc9 csum 0xc9 v000593e0 ~ld connect to network 'obmar' ... ............................... ..................................................................... [NTP]: 2022-07-03+09:28:43 SERIAL: 11 41 add inverter: PV HM 800, SN: 114180113742 RF24 Amp Pwr: RF24_PA_HIGH Radio Config: SPI Frequency = 1 Mhz Channel = 3 (~ 2403 MHz) RF Data Rate = 250 KBPS RF Power Amplifier = PA_HIGH RF Low Noise Amplifier = Enabled CRC Length = Disabled Address Length = 5 bytes Static Payload Length = 32 bytes Auto Retry Delay = 250 microseconds Auto Retry Attempts = 0 maximum Packets lost on current channel = 0 Retry attempts made for last transmission = 9 Multicast = Disabled Custom ACK Payload = Disabled Dynamic Payloads = Disabled Auto Acknowledgment = Disabled Primary Mode = RX TX address = 0xdeadbeef01 pipe 0 (closed) bound = 0xdeadbeef01 pipe 1 ( open ) bound = 0x1234567801 pipe 2 (closed) bound = 0xc3 pipe 3 (closed) bound = 0xc4 pipe 4 (closed) bound = 0xc5 pipe 5 (closed) bound = 0xc6 ---------------------------------------- Welcome to AHOY! point your browser to http://192.168.178.61 to configure your device ---------------------------------------- Free heap: 0x8ab8 Inverter #0 no Payload received! Requesting Inverter SN 114180113742 Transmit 27 | 15 80 11 37 42 78 56 34 12 80 0B 00 62 C1 61 46 00 00 00 05 00 00 00 00 6A A4 3D Received 27 bytes channel 3: 95 80 11 37 42 80 11 37 42 01 00 01 00 0A 00 03 00 00 01 49 00 48 00 EC 00 00 70 Manchmal geht auch die Verbindung zu Mqtt verloren. Hab ich aber noch keinen Log .
Hallo Oswald S., bitte hier keine Stacktraces / Exceptions reinpasten! Wir kennen das Problem und versuchen es seit einiger Zeit u.a. im folgrnden Github Issue zu analysieren: https://github.com/grindylow/ahoy/issues/15 Dort steht auch, wie Du Deinen Exception Code decodieren kannst. Das geht nur mit dem Original Hex/Binary file das auf Deinem ESP8266 geflasht wurde. Wir können also mit den Daten gar nichts anfangen sic ! Wenn Du weiteren Code hier pasten willst dann verwende bitte die [ code ] und [ / code ] Syntax (siehe unten beim Eingabefeld) um es für uns alle leserlich zu gestalten. Danke!
Hallo Oswald S., ansonsten scheint er ja einen WLAN Router zu erreichen, das nRF24L01+ Modul zu initialisieren und auf die Anfrage eine Antwort vom Wechselrichter zu bekommen und es ist soweit alles schick außer/nach dem Reboot.
Ach ja und das Problem mit dem Neuaufbau der MQTT Verbindung hatten wir vermeintlich schon gelöst: https://github.com/grindylow/ahoy/issues/68 Vielleicht ist die WLAN Verbindung doch nicht so stabil wie man es aus den o.a. Logfile annehmen könnte ? Das ist zumindest bei mir m.E. das Problem (mein Router ist im Keller und der ESP unterm Dach) da geht es nur in bestimmten Ecken des Zimmers und auch nur wenn die Nachbarn (bzw. deren WLAN Geräte) schlafen.
Hallo, gibt es denn schon erfolge bzgl. Hoymiles und Limitierung ? Ich habe das, was ich hier gelesen habe mal testweise eingebaut, leider bekomme auch ich keine Antwort oder eine Limitierung.
1 | void sendPowerLimitPacket(uint64_t invId, uint8_t limit, bool calcCrc = true) { |
2 | //DPRINTLN(DBG_VERBOSE, F("hmRadio.h:sendCmdPacket")); |
3 | memset(mTxBuf, 0, MAX_RF_PAYLOAD_SIZE); |
4 | mTxBuf[0] = 0x51; // message id |
5 | CP_U32_BigEndian(&mTxBuf[1], (invId >> 8)); |
6 | CP_U32_BigEndian(&mTxBuf[5], (DTU_ID >> 8)); |
7 | mTxBuf[9] = 0x5a; |
8 | mTxBuf[10] = 0x5a; |
9 | mTxBuf[11] = 0x32; |
10 | |
11 | if(calcCrc) { |
12 | mTxBuf[12] = Hoymiles::crc8(mTxBuf, 12); |
13 | sendPacket(invId, mTxBuf, 13, false); |
14 | DPRINT(DBG_INFO, "Transmit (Limit) " + String(13) + " | "); |
15 | dumpBuf(NULL, mTxBuf, 13); |
16 | } |
17 | } |
Der Request sollte 50% limitieren. Die Payload dazu ist:
1 | [14:52:39]I: Transmit (Limit) 13 | 51 73 10 90 25 78 56 34 12 5A 5A 32 BD |
Wäre cool, wenn wir das hinbekommen, mein 2ter PWM is bereits nach Monaten Dauerbetrieb schon abgeraucht. Den nutze ich um die Stromstärke für den HM anzupassen. Marcel
Marcel A. schrieb: > Der Request sollte 50% limitieren. > > Die Payload dazu ist: > [code] > [14:52:39]I: Transmit (Limit) 13 | 51 73 10 90 25 78 56 34 12 5A 5A 32 > BD Das geht anscheinend bisher nur mit "meinem" MI-1500. Kannst du mal bitte diese Variante auch noch probieren? Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Hallo Ziyat, ich hab den test code mal angepasst auf:
1 | void sendPowerLimitPacket(uint64_t invId, uint8_t limit, bool calcCrc = true) { |
2 | //DPRINTLN(DBG_VERBOSE, F("hmRadio.h:sendCmdPacket")); |
3 | memset(mTxBuf, 0, MAX_RF_PAYLOAD_SIZE); |
4 | mTxBuf[0] = 0x51; // message id |
5 | CP_U32_BigEndian(&mTxBuf[1], (invId >> 8)); |
6 | CP_U32_BigEndian(&mTxBuf[5], (DTU_ID >> 8)); |
7 | mTxBuf[9] = 0x5a; |
8 | mTxBuf[10] = 0x5a; |
9 | mTxBuf[11] = 0x64; // 100% |
10 | mTxBuf[12] = 0x32; // 50W |
11 | |
12 | if(calcCrc) { |
13 | mTxBuf[13] = Hoymiles::crc8(mTxBuf, 13); |
14 | sendPacket(invId, mTxBuf, 14, false); |
15 | DPRINT(DBG_INFO, "Transmit (Limit) " + String(14) + " | "); |
16 | dumpBuf(NULL, mTxBuf, 14); |
17 | } |
18 | } |
welches dann in folgende Payload übergeht:
1 | [16:21:06]I: Transmit (Limit) 14 | 51 73 10 90 25 78 56 34 12 5A 5A 64 32 D9 |
Leider ändert sich daran nichts :/ Ich habe einen HM400, deswegen musste ich auf 50W runter. Warum soll denn die Zahl davor 100% sein ? Marcel
Wie kann man die Befehle zur Limitierung senden?
Rene M. schrieb: > Wie kann man die Befehle zur Limitierung senden? Ich hab seit ein paar Tagen die EspHome Version fertig und teste die gerade (ich mache dann ein PullRequest ins ahoy repo, sobald ich zufrieden damit bin). Da habe ich mir einen Schalter eingebaut der dann die o.g. Funktion aufruft. Es ist derzeit noch nicht im code eingebaut und man müsste es sich immer selber bauen. Damals war es möglich ein Commando in der Seriellen Konsole aufzurufen, weiß aber nicht wie das gemacht wurde. Marcel
:
Bearbeitet durch User
Ok danke. Da bin ich schon gespannt darauf. Danke für die tolle Arbeit an alle!
Hallo zusammen, erst einmal vielen vielen Dank an alle die das Projekt hier ins Leben gerufen haben!!! Bei mir mit meinem Hoymiles HM-600 läuft das ganze jetzt schon ca. zwei Wochen ohne nennenswerte Probleme. Jetzt habe ich allerdings doch mal eine Frage: Im Setup bei MQTT kann man da nur eine IP adresse eingeben? Eine dyndns adresse wird nicht angenommen und es erscheint beim nachschauen die IP 0.0.0.0 Hat da wer ein Tipp für mich? Liebe Grüße Andreas
Die IP-Adresse von MQTT ist die Adresse zum MQTT-Server gemeint. ;)
Ja, soweit klar. Aber man kann nur eine IP adresse eingeben. Nicht z.B. „xyz.ddns.net“
Der Mqtt Server ist doch genauso wie dein esp im Heimnetzwerk, wieso dann eine Dyndns Adresse?
Es spielt doch gar keine Rolle wor ein MQTT Server steht ! Das kann intern oder extern sein. Mein Vorschlag für die Programmierer wäre: MQTT ein/aus wählbar Wenn MQTT ein, dann A) IP Addr und Timeout in ms angebbar B) DNS Adr. und Timeout in ms angebbar Reihenfolge zur Erreichbarkeit Auswahl: (folgende Optionen nur wählbar, wenn A) bzw. B) auch ausgefüllt) Nur A) Nur B) Erst A) und wenn nicht erreichbar bis Timeout dann B) Erst B) und wenn nicht erreichbar bis Timeout dann A) So was in der Art würde vielleicht Sinn machen. Wer einen github Account hat, kann das ja gerne kopieren und dort hinterlegen. Ich habe da aktuell keinen Account.
Tobi D. schrieb: > Der Mqtt Server ist doch genauso wie dein esp im Heimnetzwerk, wieso > dann eine Dyndns Adresse? Sie können einen Server außerhalb in der Cloud haben
Herbert K. schrieb: > Mein Vorschlag für die Programmierer wäre: > > MQTT ein/aus wählbar Schreib es auf Github als feature. :) https://github.com/grindylow/ahoy/issues
Mir ist etwas interessantes aufgefallen, für was ich keine Lösung finden kann: - Mit ahoy v0.4.14 - alles funtkioniert bestens. - Mit ahoy v0.4.20 - "Inverter is available but is not producing" Einstellungen sind alle gleich - getestet per OTA-Update als auch direkt aus Arduino auf den 8266 geladen. Ich bin leider kein Programmierer und kann nicht so weit in die Materie hereinschauen wie ihr, eventuell hilft aber der Hinweis
Wenn die Spannung AC = > 253 V beträgt, produziert der Wechselrichter nicht
dax schrieb: > Wenn die Spannung AC = > 253 V beträgt, produziert der Wechselrichter > nicht Der Wechselrichter produziert korrekt. Ich habe zwei ESP8266 mit NRF24l01+ hier aufgebaut um die Versionen zu testen. Mit Version 0.4.14 bekomme ich die nachweislich korrekten Werte angezeigt, mit Version 0.4.20 den oben beschriebenen Fehler. Es liegt nicht an der technischen Installation; es scheint zwischen beiden Versionen irgendeinen Unterschied zu geben, welcher zu dieser Meldung führt.
oxylog schrieb: > Es liegt nicht an der technischen Installation; es scheint zwischen > beiden Versionen irgendeinen Unterschied zu geben, welcher zu dieser > Meldung führt. Hast Du die Pinout Einstellungen mal angepasst?
dax schrieb: > Wenn die Spannung AC = > 253 V beträgt, produziert der Wechselrichter > nicht Ist ja auch irgendwie erwartungsgemäß. Interessant wäre dann auch mal das Event-Log. Da müsste dann ein code 141 'Grid overvoltage' drin stehen.
Yes, die Einstellungen sind gleich wie bei meinem Testaufbau. Im Webinterface, in Arduino direkt in der Konfiguration - Habe versucht solche Fehler zu vermeiden. 0.4.14 mit CE =15, CS =2 und IRQ=0 läuft anstandslos - gleiche Settings führen unter 0.4.20 zur Fehlermeldung. Kann das an einer NRF-Library-Version hängen?
Hallo, habe selber einen Hoymiles HMT-2250. Wurde dieser schon erfolgreich mit dem Projekt zum laufen gebracht?
oxylog schrieb: > Yes, die Einstellungen sind gleich wie bei meinem Testaufbau. > Im Webinterface, in Arduino direkt in der Konfiguration - Habe versucht > solche Fehler zu vermeiden. > 0.4.14 mit CE =15, CS =2 und IRQ=0 läuft anstandslos - gleiche Settings > führen unter 0.4.20 zur Fehlermeldung. > Kann das an einer NRF-Library-Version hängen? Ok, jetzt habe ich doch einen Ansatz gefunden. Nochmals alle Bibliotheken aktualisiert, nochmals kompiliert - alle Einstellungen in Arduino überprüft - jetzt geht es. Sorry für den Trouble!
Norman Z. schrieb: > Hallo, habe selber einen Hoymiles HMT-2250. Wurde dieser schon > erfolgreich mit dem Projekt zum laufen gebracht? Hier steht im Datenblatt als Kommunikationsmedium "Sub-1G wireless". Das ist kein Nordic Semiductor NRF24 2.4GHz Modul. Wird also nicht funktionieren (würde ich annehmen)
Wechselrichter hoymiles HMT-xxxx HMS-xxxx DTU-Pro-S (Sub-1G wireless) ist vermutlich eine andere Übertragungstechnik / ein anderes Protokoll wie hoymiles HM-xxxx (nRF24). Bitte hier über HM-xxxx diskutieren und nicht diesen Beitrag kapern mit HMT-xxxx, HMS-xxxx, DTU-Pro-S. Bitte hier über HMS-xxxx diskutieren. Hab ich mal extra dafür angelegt. Beitrag "Wechselrichter Hoymiles HMS-xxxx Sub-1G wireless" Bitte hier über HMT-xxxx diskutieren. Hab ich mal extra dafür angelegt. Beitrag "Wechselrichter Hoymiles HMT-xxxx Sub-1G wireless" Und für Hoymiles Gateway DTU-Pro-S bitte hier diskutieren: Beitrag "Hoymiles Gateway DTU-Pro-S mit "-S" Sub-1G wireless" Danke fürs Verständnis.
:
Bearbeitet durch User
Ich würde gerne mal OpenDTU mit einem HM-800 ausprobieren. Leider gibt es von den ESP32 so viele Versionen dass ich nicht durchblicke. Ist das hier der richtige? https://www.reichelt.at/at/de/entwicklungsboard-esp32-wroom-32d-esp32devkitc32d-p311733.html?&trstct=pos_4&nbc=1 Ich finde auf git bei tbnonody leider nirgends eine vollständige Bezeichnung.
Hallo, hattet ihr das schon mal das die MQTT Nachrichten anscheinend defekt sind? Hier HM-800 an ESP8266. Siehe Screenshot. Ich habe auch festgestellt das wenn der MQTT Server mal weg ist (oder man die falsche IP vergibt) der ESP nach einiger Zeit nicht mehr reagiert.
Hier noch das ioBroker Protokoll dazu.
Hmm bei mir passt alles. Welche Version hast du?
Das ist die 0.4.20. Erst läuft auch alles normal... Dann nach einiger Zeit fängt das an.
:
Bearbeitet durch User
> hattet ihr das schon mal das die MQTT Nachrichten anscheinend defekt > sind? Hatte ich im Zusammenspiel PubSubClient und IOBroker MQTT schon öfters, nicht nur beim Ahoy.
> Ich hab seit ein paar Tagen die EspHome Version fertig und teste die > gerade (ich mache dann ein PullRequest ins ahoy repo, sobald ich > zufrieden damit bin). Wenn du noch Tester brauchst :)
Marcel A. schrieb: > Hallo Ziyat, >
1 | > [16:21:06]I: Transmit (Limit) 14 | 51 73 10 90 25 78 56 34 12 5A 5A 64 |
2 | > 32 D9 |
3 | > |
> > Leider ändert sich daran nichts :/ Ich habe einen HM400, deswegen musste > ich auf 50W runter. Warum soll denn die Zahl davor 100% sein ? > > Marcel Hallo Marcel Dein Transmit waere korrekt. 100% wird, wenn danach noch ein Byte kommt (abs. Watt) immer ignoriert, aber ich lasse immer 100% drin, zum debuggen ist einfacher. Ich denke das command:0x51 mit subcommand:0x5a5a funktioniert bei den HM's nicht, du bist der 2. Tester. Schade :-( Da ich kein HM habe, kann leider auch nicht sniffen, aber bald gibts bei mir einen HM-1500, dann kann ich es sicher heraus finden. Gruss
@Ziyat T. das wäre super. Ich bin nämlich mit meinem Latein am Ende. Habe mir die Doku nochmal angeschaut, aber irgendwann iser der Kopf nur noch voll. :(
1N 4. schrieb: >> Ich hab seit ein paar Tagen die EspHome Version fertig und teste die >> gerade (ich mache dann ein PullRequest ins ahoy repo, sobald ich >> zufrieden damit bin). > > Wenn du noch Tester brauchst :) Sehr gerne. Du kannst meinen Fork checken: https://github.com/a-marcel/ahoy/tree/main/tools/esphome Ich würde gern wissen ob es auf einem esp8266 funktioniert. Ebenfalls habe ich Probleme die Payload in ein array zu packen und diese dann an den ESP Logger zu übergeben. Derzeit loggt er noch direkt zu Serial und das sieht man später nicht im EspHome log. Und wenn du mit der Readme nicht klar kommst, nehme ich sehr gerne Kommentare an. Bisher läuft sie seit 1 Woche gut durch. Mit kleineren Aussetzern aber keinen Reboot. Vielen Dank Marcel
:
Bearbeitet durch User
>> Wenn du noch Tester brauchst :) > Sehr gerne. Du kannst meinen Fork checken: > https://github.com/a-marcel/ahoy/tree/main/tools/esphome > Ich würde gern wissen ob es auf einem esp8266 funktioniert. Ich versuche das mal über das IOBroker - ESPHome Plugin zu kompilieren :)
Hallo Daniel R., hat eigentlich schon mal jemand versucht den Code von gitee.com (iotloves) für einen STM32F4xx zu übersetzen bzw. um dann den Code im Step Debugger durchzugehen, wie der die Daten zur Power Limitierung an die HM-Wechselrichter versenden / verpacken würde ? Das müsste doch in einer PlatformIO Umgebung oder einem STM IDE ohne weitere Bibliotheken gehen ... es scheint zumindest alles vorhanden. Ich strauchle immer noch über die Vorbelegung der beiden Laufzeit-Variablen TotalIndex_Para und Index_Para in den UsartNrf3_Send_PackDevControl() Aufrufen in der UsartNrf_Send_DevControlUpdate() Methode:
1 | 2542: Uart_SendBufferLen = UsartNrf3_Send_PackDevControl((u8 *)MIMajor[PortNO].Property.Id, (u8 *)MIMajor[PortNO].Property.Id, (u16)(SubCmd << 8), (u8 *)MIMajor[PortNO].Property.Pass.Data + Index_Para, 0x81 + ((Index_Para + 4) / 16), TotalIndex_Para - Index_Para); |
bzw. CurSendRecLostPackageNO und CurSendRecLastPackageNO in den Aufrufen in UsartNrf3_Send_DevControlUpdate:
1 | 2603: Uart_SendBufferLen = UsartNrf3_Send_PackDevControl(target_adr, rout_adr, (u16)(SubCmd << 8), (u8 *)MIMajor[PortNO].Property.Pass.Data, (CurSendRecLastPackageNO + 1) | 0x80, TotalIndex_Para); |
In UsartNrf3_Send_PackDevControl() wird dann schließlich das Paket zusammengebaut:
1 | /*********************************************** |
2 | ** Function name: Three-generation protocol device control package |
3 | ** Descriptions: |
4 | ** input parameters: ? |
5 | ** output parameters: ? |
6 | ** Returned value: ? |
7 | *************************************************/ |
8 | u8 UsartNrf3_Send_PackDevControl(u8 *target_adr, u8 *rout_adr, u16 ControlMode, u8 *ControlData, u8 nub, u8 Num) |
9 | { |
10 | vu8 i = 0; |
11 | vu16 TempCrc = 0; |
12 | vu8 temp_dat[UART_LEN]; |
13 | vu16 DatCrc = 0xffff; |
14 | memset((u8 *)temp_dat, 0, sizeof(temp_dat)); |
15 | memset((u8 *)Uart_SendBuffer, 0, UART_LEN); |
16 | Uart_SendBuffer[0] = STX; //header |
17 | temp_dat[0] = DEVCONTROL_ALL; //command |
18 | memcpy((u8 *)&temp_dat[1], target_adr, 4);//Source address |
19 | memcpy((u8 *)&temp_dat[5], rout_adr, 4);//Destination address |
20 | temp_dat[9] = 0x81;// |
21 | |
22 | if((nub & 0x0f) == 1) |
23 | { |
24 | temp_dat[10] = (u8)(ControlMode >> 8); //Control type |
25 | temp_dat[11] = (u8)(ControlMode); //Control type |
26 | } |
27 | |
28 | memcpy((u8 *) & (temp_dat[12]), ControlData, Num); //Control parameters |
29 | |
30 | for(i = 10; i < 12 + Num + 1; i++) |
31 | { |
32 | if((i - 10) % 2 == 1) |
33 | { |
34 | TempCrc = (u16)((temp_dat[i - 1] << 8) | (temp_dat[i])); |
35 | DatCrc = CalcCRC16t(TempCrc, DatCrc); |
36 | } |
37 | } |
38 | |
39 | temp_dat[12 + Num] = (u8)(DatCrc >> 8); |
40 | temp_dat[13 + Num] = (u8)(DatCrc); |
41 | temp_dat[14 + Num] = Get_crc_xor((u8 *)&temp_dat[0], 15 + Num); |
42 | i = ForwardSubstitution((u8 *)&Uart_SendBuffer[1], (u8 *)&temp_dat[0], (15 + Num)); //Forward replacement |
43 | Uart_SendBuffer[(i + 1)] = ETX; // footer |
44 | memset((u8 *)temp_dat, 0, sizeof(temp_dat)); |
45 | return (i + 2); |
46 | } |
Mit den folgenden Annahmen:
1 | // STX: 0x7e |
2 | // MainCmd: 0x51 DEVCONTROL_ALL/REQ_ARW_DAT_ALL |
3 | // target_adr: 0x73109025 |
4 | // rout_adr: 0x78563412 |
5 | // SubCmd: 0x0B Type_ActivePowerContr |
6 | // ControlMode: (u16)(SubCmd << 8): 0x0B00 |
7 | // *ControlData: (u8 *)MIMajor[PortNO].Property.Pass.Data: 0x00000000 00000000 00000000 00000000 0000 |
8 | // PowerPFDev: 0x03EB0001 // SetValut[2], Desc[2] |
9 | // nub: (CurSendRecLastPackageNO + 1) | 0x80: 0x81 |
10 | // Num: TotalIndex_Para: 4 ? |
11 | // ETX: 0x7f |
ergibt sich diese Paketstruktur
1 | temp_dat[i]: -1, 0, 1..4, 5..8, 9, 10-11, 12-15, 16 |
2 | STX, MainCmd, target_adr[4], rout_adr[4], 0x81, 0x0B00, 0x00000000, ETX |
und es sollte evtl. irgendwas wie das Folgende herauskommen: 0x7e 0x51 0x73109025 0x78563412 0x81 0x0B00 0x03EB0001 0x7f Über den Wert aus PowerPFDev 0x03EB0001 bzw. Pass.Data[4] wird noch mit CalcCRC16t und Get_crc_xor eine/mehrere Prüfsummen gebildet. PS: die InverterMajor Struktur sieht wie folgt aus:
1 | InverterMajor |
2 | Property |
3 | Pre_Id[2] (vu8) |
4 | Id[4] (vu8) |
5 | Port (PortType) |
6 | Id_In_Phase (vu8) |
7 | Acq_Switch (vu8) |
8 | Power_Limit (vu16) |
9 | Pass (PassValueType) |
10 | PowerPFDev (PowerPFDevType) |
11 | SetValut[2] (vu8) |
12 | Desc[2] (vu8) |
13 | ClearAlarmDev (ClearAlarmDevType) |
14 | WCode[2] (vu8) |
15 | EletricSet (EletricSetType) |
16 | Info[2] (vu8) |
17 | Data[16] (vu8) |
18 | PassWordSet (PassWordSetType) |
19 | PWO[4] (vu8) |
20 | PWN[4] (vu8) |
21 | ATTime[2] (vu8) |
22 | Data[18] (vu8) |
23 | PropertyMsg[30] (vu8) |
Und hier sind die für MI und HM definierten Lower Bytes der Pre_Id's die Id sind jeweils die lower 4 Bytes der Inverter Serial No. Serial Number: Pre_Id[2] + Id[4]
1 | typedef enum |
2 | { |
3 | MI_NO = 0, |
4 | MI_250W = 0x01, |
5 | MI_500W_A = 0x02, |
6 | MI_500W_B = 0x03, |
7 | MI_1000W_A = 0x04, |
8 | MI_1000W_B = 0x05, |
9 | MI_1000W_C = 0x06, |
10 | MI_1000W_D = 0x07, |
11 | Pro_A = 0x08, |
12 | Pro_B = 0x09, |
13 | Pro_C = 0x0a, |
14 | Pro_D = 0x0b, |
15 | HM_250W = 0x0C, |
16 | HM_500W_A = 0x0D, |
17 | HM_500W_B = 0x0E, |
18 | HM_1000W_A = 0x0F, |
19 | HM_1000W_B = 0x10, |
20 | HM_1000W_C = 0x11, |
21 | HM_1000W_D = 0x12, |
22 | } PortType; |
Hallo Daniel R., alternativ geht es nach der Implementierung in UsartNrf_Send_PackSetPowerLimitCommand()
1 | /*********************************************** |
2 | ** Function name: The second-generation protocol sets the micro-inverse power package |
3 | ** Descriptions: |
4 | ** input parameters: |
5 | ** output parameters: |
6 | ** Returned value: |
7 | *************************************************/ |
8 | u8 UsartNrf_Send_PackSetPowerLimitCommand(u8 *target_adr, u8 *rout_adr, int8_t MainCmd, u16 SubCmd) |
9 | { |
10 | vu8 i = 0; |
11 | vu8 temp_dat[UART_LEN]; |
12 | memset((u8 *)temp_dat, 0, sizeof(temp_dat)); |
13 | Uart_SendBuffer[0] = STX;//start |
14 | temp_dat[0] = (u8)MainCmd; //command |
15 | memcpy((u8 *)&temp_dat[1], target_adr, 4); |
16 | memcpy((u8 *)&temp_dat[5], rout_adr, 4); |
17 | #ifdef DTU3PRO |
18 | |
19 | if((Dtu3Detail.Property.Zero_Export_Switch == 1) || |
20 | (Dtu3Detail.Property.DRM_Limit_Switch == 1) || |
21 | (Dtu3Detail.Property.Phase_Balance_Switch == 1) || |
22 | (Dtu3Detail.Property.SunSpec_Switch == 1)) |
23 | { |
24 | if(MIMajor[PortNO].Property.Acq_Switch == 0) |
25 | { |
26 | //1000w shutdown special control micro-inverse control of 1-to-4 with the last 8 digits of the ID less than 0x50000000 |
27 | if((MIMajor[PortNO].Property.Id[0] < 0X50) && ((MIMajor[PortNO].Property.Pre_Id[1] == 0X60) || (MIMajor[PortNO].Property.Pre_Id[1] == 0X61))) |
28 | { |
29 | temp_dat[9] = (u8)(SubCmd >> 8); //5a5a |
30 | temp_dat[10] = (u8)(SubCmd & 0XFF); |
31 | temp_dat[11] = 11; |
32 | // temp = 35*4*10=1400=0x0578; |
33 | temp_dat[12] = 0X05; |
34 | temp_dat[13] = 0X78; |
35 | temp_dat[14] = Get_crc_xor((u8 *)&temp_dat[0], 14); //CRC |
36 | i = ForwardSubstitution((u8 *)&Uart_SendBuffer[1], (u8 *)&temp_dat[0], 15); //forward substitution |
37 | } |
38 | else |
39 | { |
40 | temp_dat[9] = (u8)(CONTROL_OFF_SUB >> 8); //aa55 |
41 | temp_dat[10] = (u8)(CONTROL_OFF_SUB & 0XFF); |
42 | temp_dat[11] = Get_crc_xor((u8 *)&temp_dat[0], 11); //CRC |
43 | i = ForwardSubstitution((u8 *)&Uart_SendBuffer[1], (u8 *)&temp_dat[0], 12); //forward substitution |
44 | } |
45 | } |
46 | else |
47 | { |
48 | temp_dat[9] = (u8)(SubCmd >> 8); //5a5a |
49 | temp_dat[10] = (u8)(SubCmd & 0XFF); |
50 | temp_dat[11] = (u8)(MIMajor[PortNO].Property.Power_Limit * 10 / (EVERY_PORT_POWER * (UsartNrf_GetInvterType((u8 *)MIMajor[PortNO].Property.Pre_Id)))); //Power limit percentage |
51 | temp_dat[12] = (u8)(MIMajor[PortNO].Property.Power_Limit >> 8); //High 8-bit power limit |
52 | temp_dat[13] = (u8)(MIMajor[PortNO].Property.Power_Limit & 0x00ff); //Low power limit 8 bits |
53 | temp_dat[14] = Get_crc_xor((u8 *)&temp_dat[0], 14); //CRC |
54 | i = ForwardSubstitution((u8 *)&Uart_SendBuffer[1], (u8 *)&temp_dat[0], 15); //forward substitution |
55 | } |
56 | } |
57 | else |
58 | { |
59 | #endif |
60 | temp_dat[9] = (u8)(SubCmd >> 8); //5a5a |
61 | temp_dat[10] = (u8)(SubCmd & 0XFF); |
62 | temp_dat[11] = (u8)(MIMajor[PortNO].Property.Power_Limit * 10 / (EVERY_PORT_POWER * (UsartNrf_GetInvterType((u8 *)MIMajor[PortNO].Property.Pre_Id)))); //Power limit percentage |
63 | temp_dat[12] = (u8)(MIMajor[PortNO].Property.Power_Limit >> 8); //High 8-bit power limit |
64 | temp_dat[13] = (u8)(MIMajor[PortNO].Property.Power_Limit & 0x00ff); //Low power limit 8 bits |
65 | temp_dat[14] = Get_crc_xor((u8 *)&temp_dat[0], 14); //CRC |
66 | i = ForwardSubstitution((u8 *)&Uart_SendBuffer[1], (u8 *)&temp_dat[0], 15); //forward substitution |
67 | #ifdef DTU3PRO |
68 | } |
69 | |
70 | #endif |
71 | Uart_SendBuffer[(i + 1)] = ETX; //end |
72 | memset((u8 *)temp_dat, 0, sizeof(temp_dat)); |
73 | return (i + 2); |
74 | } |
Hier im Beispiel ein HM-1161 mit bis zu 2700 W maximaler Spitzenleistung. Das müsste m.E. dann folgendes Paket ergeben:
1 | 1000W: 0x51 0x73109025 0x78563412 0xa5a5 0x03 0x03E8 CRC8 |
2 | 1500W: 0x51 0x73109025 0x78563412 0xa5a5 0x05 0x05DC CRC8 |
3 | 400W: 0x51 0x73109025 0x78563412 0xa5a5 0x01 0x0100 CRC8 |
Hierbei ist 0x05 bzw. 0x03 der Wert des (PowerLimit * 10) dividiert durch die maximale Leistung (9*300W=2700W) des Inverters (bei 300 W pro "Kanal") wobei die HM-Modelle offenbar eine maximale Spitzenleistung zwischen 2100 W und 3000 W zur Validierung der führenden Stelle verwenden bzw. verkraften ? Im obigen Beispiel also:
1 | (1000*10)/(300*9)=10000/2700=3.70->(u8) 3 |
2 | (1500*10)/(300*9)=15000/2700=5.55->(u8) 5 |
3 | (400*10)/(300*9)= 4000/2700=1.58->(u8) 1 |
Danach folgt in zwei weiteren Bytes das PowerLimit nochmal als Hex-Wert, hier 0x05DC (1500 W) bzw. 0x03E8 (1000 W) oder 0x0100 (400 W). Hier noch die Anzahl der "Kanäle" bzw. der maximale Spitzenlast-Leistungsindex der Inverter:
1 | typedef enum |
2 | { |
3 | InitInverterType = 0, |
4 | Inverter_250 = 1, |
5 | Inverter_500 = 2, |
6 | Inverter_1000 = 4, |
7 | Inverter_Pro = 7, |
8 | Inverter_HM_OneToOne = 8, |
9 | Inverter_HM_OneToTwo = 9, |
10 | Inverter_HM_OneToFour = 10, |
11 | } InverterType; |
und die entsprechende Routine um den Invertertyp zu bestimmen.
1 | /*********************************************** |
2 | ** Function name: Get the micro-inverse type |
3 | ** Descriptions: |
4 | ** input parameters: ? |
5 | ** output parameters: ? |
6 | ** Returned value: ? |
7 | *************************************************/ |
8 | |
9 | InverterType UsartNrf_GetInvterType(u8 *pId) |
10 | { |
11 | if((u8)(((((u16)pId[0] << 8) | pId[1]) >> 4) & 0xff) == 0x26) // 0x0260 |
12 | { |
13 | return Inverter_Pro; // 7*300W=2100W |
14 | } |
15 | else if((u8)(((((u16)pId[0] << 8) | pId[1]) >> 4) & 0xff) == 0x12) // 0x0120 |
16 | { |
17 | return Inverter_HM_OneToOne; // 8*300W=2400W |
18 | } |
19 | else if((u8)(((((u16)pId[0] << 8) | pId[1]) >> 4) & 0xff) == 0x14) // 0x0140 |
20 | { |
21 | return Inverter_HM_OneToTwo; // 9*300W=2700W |
22 | } |
23 | else if((u8)(((((u16)pId[0] << 8) | pId[1]) >> 4) & 0xff) == 0x16) // 0x0160 |
24 | { |
25 | return Inverter_HM_OneToFour; // 10*300W=3000W |
26 | } |
27 | else |
28 | { |
29 | if(((pId[1] & 0xf0) == 0x10) || ((pId[1] & 0xf0) == 0x20)) //0x0010 || 0x0020 |
30 | { |
31 | if(((pId[0] == 0x10) && (pId[1] == 0x22)) || ((pId[0] == 0x11) && (pId[1] == 0x21))) // 0x1022 || 0x1121 |
32 | { |
33 | return Inverter_HM_OneToOne; // 8*300W=2400W |
34 | } |
35 | else if(((pId[0] == 0x10) && (pId[1] == 0x19)) || ((pId[0] == 0x10) && (pId[1] == 0x29))) // 0x1019 || 0x1029 |
36 | { |
37 | return InitInverterType; // 0*300W=0W |
38 | } |
39 | else // others |
40 | { |
41 | return Inverter_250; // 1*300W=300W |
42 | } |
43 | } |
44 | else if(((pId[1] & 0xf0) == 0x30) || ((pId[1] & 0xf0) == 0x40)) //500w // 0x0030 || 0x0040 |
45 | { |
46 | if(((pId[0] == 0x10) && (pId[1] == 0x42)) || ((pId[0] == 0x11) && (pId[1] == 0x41))) // 0x1042 || 0x1141 |
47 | { |
48 | return Inverter_HM_OneToTwo; // 9*300W=2700W |
49 | } |
50 | else if(((pId[0] == 0x10) && (pId[1] == 0x39)) || ((pId[0] == 0x10) && (pId[1] == 0x49))) // 0x1039 || 0x1049 |
51 | { |
52 | return InitInverterType; // 0*300W=0W |
53 | } |
54 | else // others |
55 | { |
56 | return Inverter_500; // 2*300W=600W |
57 | } |
58 | } |
59 | else if(((pId[1] & 0xf0) == 0x50) || ((pId[1] & 0xf0) == 0x60)) // 0x0050 || 0x0060 |
60 | { |
61 | if(((pId[0] == 0x10) && (pId[1] == 0x62)) || ((pId[0] == 0x11) && (pId[1] == 0x61))) // 0x1062 || 0x1161 |
62 | { |
63 | return Inverter_HM_OneToFour; // 10*300W=3000W |
64 | } |
65 | else if((pId[0] == 0x10) && (pId[1] == 0x69)) // 0x1069 |
66 | { |
67 | return InitInverterType; // 0*300W=0W |
68 | } |
69 | else // others |
70 | { |
71 | return Inverter_1000; // 4*300W=1200W |
72 | } |
73 | } |
74 | else if((pId[0] == 0x12) && (pId[1] == 0x61)) // 0x1261 |
75 | { |
76 | return Inverter_Pro; // 7*300W=2100W |
77 | } |
78 | |
79 | return InitInverterType; // 0*300W=0W |
80 | } |
81 | } |
Hi Stefan, Stefan T. schrieb: > hat eigentlich schon mal jemand versucht den Code von gitee.com > (iotloves) für einen STM32F4xx zu übersetzen bzw. um dann den Code im > Step Debugger durchzugehen, wie der die Daten zur Power Limitierung an > die HM-Wechselrichter versenden / verpacken würde ? Ja da war ich dran, jedoch denke ich das ich dann an meine grenzen gekommen bin. Ich mag es eigentlich nicht alleine zu Coden.^^ Da ich irgendwann Abends nur noch frustriert bin wenn es nicht so voran geht wie ich es mir eigentlich wünsche. ^^ > und es sollte evtl. irgendwas wie das Folgende herauskommen: > 0x7e 0x51 0x73109025 0x78563412 0x81 0x0B00 0x03EB0001 0x7f Genau das habe ich letztens auch verschickt... nur ich glaube mittlerweile das ich einen kleinen Fehler hatte (der großes bewirkt). Asche auf mein Haupt - Natührlich möchte ich auch ehrlich sein und den Fehler kongretisieren: In der Excel stehen ja die Protkolle wie Sie auszusehen haben, daran habe ich mich gehalten. Nur habe ich Bsp. 0x0B geschickt, statt 0x0B00 wie es teilweiße im *.c zu sehen ist. ;( Sobald ich heute Zuhause bin, schaue ich mir das ganze nochmal an. Habe mir jetzt paar Tage abstand gehalten und habe wieder einen freien Kopf dafür. :) Danke für eure Hilfe! > PS: die InverterMajor Struktur sieht wie folgt aus: Das habe ich auch gesehen. Edit: Ganz kurz für dumme (wie mich), ich bin kein Profi meine aber auch etwas drauf zu haben. ^^ Mir ist auch aufgefallen im Code das sogar Unterschieden wird welcher WR genau angesprochen wird. Ob es 1/2/4 Kanal hat und und und... Ich war kurz davor das ganze zu portieren, jedoch bevor ich mir die Arbeit gemacht hätte habe ich zuerstmal versucht direkt aus der Paketstruktur die Daten zum WR zu senden und erst wenn das funktioniert ein ordentliches funktionen geschrieben damit es später automatisch im Hintergrund auch richtig verarbeitet wird (so wie es im code zu sehen ist). Der einzige Knackpunkt womit ich zu kämpfen habe, ich lese ganz gerne die einzelnen Hex werte als Byte durch. Bsp: 05 06 07 08 09 0A ... Wenn mir jemand 0x0500 schreibt, bin ich immer dabei nur die 0x05 zu sehen. Was an sich falsch ist! // Daher ein Fehler von mir. ;( PS: Wenn jemand Lust hat, kann man sich mal auf Discord treffen. Einfach melden, ich schicke den Einladungslink dann.
:
Bearbeitet durch User
Gerald R. schrieb: > Ist das hier der richtige? > https://www.reichelt.at/at/de/entwicklungsboard-esp32-wroom-32d-esp32devkitc32d-p311733.html?&trstct=pos_4&nbc=1 Ja, der sollte funktionieren. Wie alle anderen ESP32devkit Klone auch.
@Stefan T. @Daniel R. > typedef enum > { > MI_NO = 0, > MI_250W = 0x01, > MI_500W_A = 0x02, > MI_500W_B = 0x03, > MI_1000W_A = 0x04, > MI_1000W_B = 0x05, > MI_1000W_C = 0x06, > MI_1000W_D = 0x07, > Pro_A = 0x08, > Pro_B = 0x09, > Pro_C = 0x0a, > Pro_D = 0x0b, > HM_250W = 0x0C, > HM_500W_A = 0x0D, > HM_500W_B = 0x0E, > HM_1000W_A = 0x0F, > HM_1000W_B = 0x10, > HM_1000W_C = 0x11, > HM_1000W_D = 0x12, > } PortType; Wie hier ersichtlich, die gite Dokumente beinhalten nicht die HM-1200,HM-1500,MI-1200, MI-1500. Diese sind nicht unbedingt RF_communication_protocol-V6.5.xlsx kompatibel. Die könnten ev. gleich sein wie MI_1000W_D/HM_1000W_D, also 4 Kanal Modelle, eben nur eventuell..Um das Sniffen kommt man nicht herum, MI-1500 hab ich schon.
Stefan T. schrieb: > und es sollte evtl. irgendwas wie das Folgende herauskommen: > 0x7e 0x51 0x73109025 0x78563412 0x81 0x0B00 0x03EB0001 0x7f - CMD 0x51 hat kein SubCMD 0x81 ???? - Warum schickst du diese 0x7e/0x7f ??? Diese sind nur für DTU-NRF intern Serial Kommunikation, die werden nicht in die Luft geschickt!! Gruss
Beitrag #7117766 wurde vom Autor gelöscht.
Axel H. schrieb: > https://www.reichelt.at/at/de/entwicklungsboard-esp32-wroom-32d-esp32devkitc32d-p311733.html?&trstct=pos_4&nbc=1 > > Ja, der sollte funktionieren. Wie alle anderen ESP32devkit Klone auch. Danke!
Hallo zusammen, also ich habe das mal probiert. Kein erfolg. Bekomme höchstens immer folgende Antwort: Received 27 bytes channel 3: f1 74 40 33 29 74 40 33 29 81 80 00 00 00 00 00 00 00 00 00 00 00 00 01 81 eb 9b Payload: 80 00 00 00 00 00 00 00 00 00 00 00 00 01 81 eb
Hallo Sigi, ich habe probiert Datenpakete zum HM-WR zu senden, so wie isnoahoy beschrieben hat. ;)
Stellt euch doch lieber ein PC mit boinc zum verbrennen überschüssigem Stroms hin. Dann hat die Wissenschaft auch noch sinnvoll was davon.
Daniel R. schrieb: > Hallo zusammen, > > also ich habe das mal probiert. Kein erfolg. > Bekomme höchstens immer folgende Antwort: > > Received 27 bytes channel 3: f1 74 40 33 29 74 40 33 29 81 80 00 00 00 > 00 00 00 00 00 00 00 00 00 01 81 eb 9b > Payload: 80 00 00 00 00 00 00 00 00 00 00 00 00 01 81 eb Wenn du das auch schreiben würdest was du geschickt hast? edit: das auch beachten Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
:
Bearbeitet durch User
> Daniel R. schrieb: > Hallo zusammen, > > also ich habe das mal probiert. Kein erfolg. > Bekomme höchstens immer folgende Antwort: > > Received 27 bytes channel 3: f1 74 40 33 29 74 40 33 29 81 80 00 00 00 > 00 00 00 00 00 00 00 00 00 01 81 eb 9b > Payload: 80 00 00 00 00 00 00 00 00 00 00 00 00 01 81 eb Was du gesendet hast, würde mich auch interessieren, denn ich habe bisher noch nicht mal eine Antwort bekommen und das was du da geschickt hast ... darauf kann man ja aufbauen und rumspielen. Danke Marcel
:
Bearbeitet durch User
Herbert K. schrieb: > Bitte hier über HM-xxxx diskutieren und nicht diesen Beitrag kapern mit > HMT-xxxx, HMS-xxxx, DTU-Pro-S. > > Bitte hier über HMS-xxxx diskutieren. Hab ich mal extra dafür angelegt. > Beitrag "Wechselrichter Hoymiles HMS-xxxx Sub-1G wireless" > > Bitte hier über HMT-xxxx diskutieren. Hab ich mal extra dafür angelegt. > Beitrag "Wechselrichter Hoymiles HMT-xxxx Sub-1G wireless" Jetzt habt ihr hier einen Thread mit weit über 1000 Beiträgen - Respekt Ich lese oft nicht nicht mehr mit - alleine weil mi das laden zu lange dauert Aber Herbert - so geht das leider auch nicht Dann mach doch Dein eigenes Forum für die Hoymiles-WR auf? Oder überzeuge die Mc-Admins hier eine eigene Unterrubrik zu machen? Einfach Leute mit für Dich uninteressante Themen abwimmeln - dann erst mal raus mit allen Mi-WR-Besitzern, hier geht es um die HM-Serie VG
Hallo Jan-Jonas, ich finde ja auch die Limitierung nicht besonders sinnig =^/ Aber das DTU-NRF Protokoll an sich ist schon interessant und bei der aktuellen Situation wäre es schon praktisch, wenn man die HM-Wechselrichter evtl. mit einem eigenen Grid Profile (laut Source Code kann man ein 1200 Punkte langes Window-Frame aufnehmen (Sinux, Sägezahn, Rechteck, etc. =^} welches dann m.E. zur Analyse und Nachbildung der aktuellen Wechselstromkurve dient) bestücken könnte oder gar die Firmware updaten kann ... Vielleicht kann man die Geräte sogar zum Inselbetrieb umfunktionieren, einfach die Hauptsicherung rausdrehen und ab geht die Luzie! Jaja ich weiß darf man natürlich alles nicht wenn (solange) es an das Niedervolt-Netz des lokalen Elektrizitätversorgers angeschlossen ist. @Daniel R., ja wäre praktisch wenn Du bei Deinen Versuchsergebnissen Transfer und Receive Meldungen dokumentieren könntest. Das erlaubt es den anderen das ggf. nachvollziehen zu können. Da geht es mir wie Dir mit den Double Werten: 0x1234 statt 0x12 0x34 etc. Danke =^! @Ziyat T., die 0x7e und 0x7f sind die Start Transmission, End Transmission Bytes, die die DTU Software für die SPI Kommunikation mit dem NRF24 Modul als STX/SOF und ETX/EOF einfügt. Die kannst DU auch gerne weglassen, weil sie evtl. von der NRF24 Bibliothek eh eingefügt werden. Ich habe Sie nur im Zusammenhang mit der analysierten Code Stelle erwähnt. Wegen den PortType's gehe ich davon aus, dies sind die einzelnen DC Eingangsports der unterschiedlichen HM- und MI-Wechselrichter Typen. Die eigentlichen Invertertypen werden in UsartNrf_GetInvterType() aus der Pre_Id also den ersten beiden Bytes der Seriennummer (z.B. 1141 bei meinem HM-600 führt zu einem Inverter_HM_OneToTwo) abgeleitet. Die DC PortType's werden hingegen bei der Berechnung der einzelnen Leistungen berücksichtigt / unterschieden, da ja jeder Eingang (DC Ports A/B/C/D) auch unterschiedlich viel Ertrag bringen kann. Das wird dann m.E. in AntiReflux.c/.h gebraucht um die Leistung aller Wechselrichter, die von einer DTU kontrolliert werden, möglichst gleichmäßig auf alle drei AC Phasen A/B/C zu verteilen. @Heinz J. und Herbert K. ja irgendwie wäre es vermutlich sinnvoll zumindest die elektronische und funkseitige Komponente der HMT- / HMS- und DTU-Pro-S in einem übersichtlichen Thread zu behandeln. Keine Ahnung ob dafür aber zwei/drei separate Threads notwendig & hilfreich sind (da vermutlich keiner von uns dort regelmäßig liest) und wie viele Anfragen dazu überhaupt reinkommen. Andererseits scheint die DTU-PRO-S eventuell sogar den selben Basis Code wie im gitee.com zu verwenden. Es gibt zumindest eine Vielzahl von #ifdef DTU3PRO und die aktivieren einen stm32f4xx anstelle eines stm32f10x Prozessors. Vielleicht finden sich ja irgendwo auf einer FCC ID Seite irgendwelche Informationen zur CPU ?
Stefan T. schrieb: > @Daniel R., ja wäre praktisch wenn Du bei Deinen Versuchsergebnissen > Transfer und Receive Meldungen dokumentieren könntest. Das erlaubt es > den anderen das ggf. nachvollziehen zu können. Da geht es mir wie Dir > mit den Double Werten: 0x1234 statt 0x12 0x34 etc. Danke =^! Kann ich heute anhängen, log sei dank. =)
Thomas B. schrieb: > Es gibt noch etliche Stellen die nicht perfekt sind, einer > Implementierung oder einer Überarbeitung bedürfen. Aber ich wollte > erstmal was lauffähiges haben. > Das Repo wäre hier zu finden: https://github.com/tbnobody/OpenDTU > Im docs Ordner gibt es auch ein paar Screenshots der WebGUI. > > In nächster Zeit (ggf. heute Abend) wird es noch ein paar "Breaking > Changes" geben was die Namen der MqTT Topics anbelangt. > Die Payload Erzeugung habe ich auch schon in die Inverter Klassen > verlegt. Dies ist jedoch mangels Test noch nicht commited. > > Über Anregungen und/oder PRs würde ich mich freuen. > > Grüße > Thomas Hallo Thomas, ich habe es gestern endlich geschaft deine ESP32 Version mit meinem HM-400 zu testen. Es lief auf anhieb ohne Probleme. 2 Dinge sind mir mit der aktuellen Version aufgefallen: - Der "Live Data" Tab sieht auf dem PC und horizontal auf dem Smartphone zusammengeschoben aus. Die 2. Tabelle verdeckt die Einheiten der ersten Tabelle - MQTT funktioniert bei mir nicht. Ich habe soweit alles eingetragen und im Info Tab steht auch das er mit dem MQTT Server verbunden ist. Es kommt aber nichts an. Leider sieht man über die Serielle auch nicht ob MQTT Daten gesendet werden, welche gesendet werden und ob es OK oder NOK ist. Eventuell liegts auch am MQTT Server?
John P. schrieb: > Thomas B. schrieb: > >> Das Repo wäre hier zu finden: https://github.com/tbnobody/OpenDTU > > Der "Live Data" Tab sieht auf dem PC und horizontal auf dem Smartphone > zusammengeschoben aus. Die 2. Tabelle verdeckt die Einheiten der ersten > Tabelle Da war ich schon dran und hab auch einen PR gemacht. Den könntest du probieren. Als nächstes wollte ich noch die NavBar und das Scrolling angucken (Beispiel: am Handy System Info nach unten scrollen und dann zu About navigieren). Dann hätte ich aber erstmal alles, was mir bisher bei Tablet / mobile aufgefallen war.
Stefan T. schrieb: > Hallo Jan-Jonas, > ich finde ja auch die Limitierung nicht besonders sinnig =^/ Aber das Es sind Leute da, die nicht in Deutschland leben, es gibt Laender da darfst du nichts einspeisen, wenn dann bezahlst du die Einspeisung auch! > Vielleicht kann man die Geräte sogar zum Inselbetrieb umfunktionieren, Die Gedanken habe ich auch gemacht, es waere nett ;-) > @Ziyat T., die 0x7e und 0x7f sind die Start Transmission, End > Transmission Bytes, die die DTU Software für die SPI Kommunikation mit > dem NRF24 Modul als STX/SOF und ETX/EOF einfügt. Das meinte ich ja auch, waere besser hier ohne STX/SOF und ETX/EOF zu kommunizieren, weil es mich irritiert, ob ihr das Packet mit oder ohne sendet > @Heinz J. und Herbert K. ja irgendwie wäre es vermutlich sinnvoll > zumindest die elektronische und funkseitige Komponente der HMT- / HMS- > und DTU-Pro-S in einem übersichtlichen Thread zu behandeln. Vorlaeufig finde es auch
Axel H. schrieb: > Da war ich schon dran und hab auch einen PR gemacht. Den könntest du > probieren. Als nächstes wollte ich noch die NavBar und das Scrolling > angucken (Beispiel: am Handy System Info nach unten scrollen und dann zu > About navigieren). Dann hätte ich aber erstmal alles, was mir bisher bei > Tablet / mobile aufgefallen war. Hatte leider noch keine Zeit das zu mergen. Werde hoffentlich heute Abend mal drüber schauen.
John P. schrieb: > - MQTT funktioniert bei mir nicht. Ich habe soweit alles eingetragen und > im Info Tab steht auch das er mit dem MQTT Server verbunden ist. Es > kommt aber nichts an. Leider sieht man über die Serielle auch nicht ob > MQTT Daten gesendet werden, welche gesendet werden und ob es OK oder NOK > ist. > Eventuell liegts auch am MQTT Server? Könntest du für solche Themen ggf. bitte einen Issue auf Github aufmachen? Dann bleibt hier der Thread für die wichtigen Themen frei. Hast du ACL's konfiguriert? Ein MQTT Client kann nämlich nicht feststellen ob er an die entsprechende Topic publishen darf. Wenn das z.B. durch ACL's (oder Benutzer rechte) verboten ist gehen die Nachrichten einfach unter. Ich habe das selbst mit einem Mosquitto (letzte Debian Pakete von mosquitto.org also Version 2.x) Broker im Einsatz und kann erst mal keine Probleme feststellen.
Thomas B. schrieb: > Axel H. schrieb: >> Da war ich schon dran und hab auch einen PR gemacht. Den könntest du >> probieren. Als nächstes wollte ich noch die NavBar und das Scrolling >> angucken (Beispiel: am Handy System Info nach unten scrollen und dann zu >> About navigieren). Dann hätte ich aber erstmal alles, was mir bisher bei >> Tablet / mobile aufgefallen war. > > Hatte leider noch keine Zeit das zu mergen. Werde hoffentlich heute > Abend mal drüber schauen. Lass Dich nicht stressen. Die PRs werden auch nicht dauerhaft in der Frequenz kommen. Hab hier gerade in Betrieb genommen und arbeite meine Liste ab. Wenn ich schon nichts zum RE des Protokolls beitragen konnte. Dafür übrigens herzlichen Dank an alle Beteiligten! Mit zu lesen und zu fiebern hat extrem viel Freude gemacht und war erkenntnisreich! Als ich im März bestellt hatte, war das die eine Kröte, die ich geschluckt habe. Dass Auslesen nur über die Cloud geht und ich da halt drauf verzichten werde. Dass das jetzt doch geht ist ganz hervorragend!
Hallo zusammen, ich lese sporadisch mit und bin auf der Suche nach einer Lösung für meinen HM-1500. Leider reichen meine Kenntnisse nicht aus, dass hier alles geschriebene nachzuvollziehen und zu verstehen. Daher meine Frage, gibt es von euch bereits ein fertiges Produkt was ich kaufen könnte? Im Moment habe ich das DTU Teil im Einsatz, allerdings gefällt es mir überhaupt nicht, dass ich so viele Daten preisgeben muss. Vielen Dank für eure Antwort. Gruß
Hallo Ronny, es gibt verschiedene Lösungen. Es kommt drauf an was für dich am einfachsten ist. Wenn du etwas fertiges haben willst, was man irgendwo kaufen kann... dann muss du wohl noch etwas warten. Außer jemand hat paar Platinen und Gehäuse übrig und könnte es für die Community Bereitstellen (gegen eine kleine Bezahlung?). Natührlich wird hier daran weiter gearbeitet. Ich habe auch noch viele Ideen was man hinzufügen kann. Jedoch wird aktuell verstärkt an der Limitierung gearbeitet. Im Grunde geht das Auslesen der Werte. Mehr aus dem Github zu entnehmen: https://github.com/grindylow/ahoy/ (hier wird m.E verstärkt gearbeitet) oder https://github.com/tbnobody/OpenDTU
:
Bearbeitet durch User
Marcel A. schrieb: > Was du gesendet hast, würde mich auch interessieren, denn ich habe > bisher noch nicht mal eine Antwort bekommen und das was du da geschickt > hast ... darauf kann man ja aufbauen und rumspielen.
1 | Poll inverter 116174403329 |
2 | 2022-07-05 14:35:30.212053 Transmit 21 | 51 74 40 33 29 78 56 34 12 81 5a 78 35 61 00 78 30 31 01 00 f8 |
3 | 2022-07-05 14:35:31.453370 Transmit 21 | 51 74 40 33 29 78 56 34 12 81 5a 78 35 61 00 78 30 31 01 00 f8 |
4 | 2022-07-05 14:35:32.693952 Transmit 21 | 51 74 40 33 29 78 56 34 12 81 5a 78 35 61 00 78 30 31 01 00 f8 |
5 | 2022-07-05 14:35:33.931475 Transmit 21 | 51 74 40 33 29 78 56 34 12 81 5a 78 35 61 00 78 30 31 01 00 f8 |
6 | 2022-07-05 14:35:33.980149 Received 27 bytes channel 3: f1 74 40 33 29 74 40 33 29 81 80 00 00 00 00 00 00 00 00 00 00 00 00 01 81 eb 9b |
7 | 2022-07-05 14:35:34.483548 Payload: 80 00 00 00 00 00 00 00 00 00 00 00 00 01 81 eb |
8 | payload has valid modbus crc |
9 | payload has 14 bytes |
10 | |
11 | Field view: int |
12 | Pos 0 1 2 3 4 5 6 7 8 9 10 11 12 13 |
13 | Hex 80 00 00 00 00 00 00 00 00 00 00 00 00 01 |
14 | >B 128 0 0 0 0 0 0 0 0 0 0 0 0 1 |
15 | |
16 | Field view: shorts |
17 | Pos 0 1 2 3 4 5 6 7 8 9 10 11 12 13 |
18 | Hex 80 00 00 00 00 00 00 00 00 00 00 00 00 01 |
19 | >H 32768 0 0 0 0 0 1 |
20 | >H 0 0 0 0 0 0 |
21 | |
22 | Field view: longs |
23 | Pos 0 1 2 3 4 5 6 7 8 9 10 11 12 13 |
24 | Hex 80 00 00 00 00 00 00 00 00 00 00 00 00 01 |
25 | >L 2147483648 0 0 |
26 | >L 0 0 0 |
27 | >L 0 0 1 |
28 | >L 0 0 |
29 | type utf-8 : utf-8 decode error |
30 | type ascii : ascii decode error |
und
1 | 2022-07-05 16:11:51.881684 Transmit 17 | 51 74 40 33 29 78 56 34 12 81 0b 00 03 eb 00 01 14 |
2 | 2022-07-05 16:11:53.117722 Transmit 17 | 51 74 40 33 29 78 56 34 12 81 0b 00 03 eb 00 01 14 |
3 | 2022-07-05 16:11:53.164533 Received 27 bytes channel 61: f1 74 40 33 29 74 40 33 29 81 80 00 00 00 00 00 00 00 00 00 00 00 00 01 81 eb 9b |
4 | 2022-07-05 16:11:53.668439 Payload: 80 00 00 00 00 00 00 00 00 00 00 00 00 01 81 eb |
Die Log hängt im Anhang. Diesen Payload bekomme ich so oft, sind in der Log 189 mal zu finden. Discord Link für alle: https://discord.gg/2jUFfKkD
:
Bearbeitet durch User
Moin, kann mal einer die Teileliste posten bitte was ich brauche, damit ich es alles zusammen löten kann :) Danke Eike
@Eike (Gast): Dies ist kein Restaurant mit Kellner ! Dies ist ein Buffet. Da muss man sich selbst bedienen ! Alles was Du wissen möchtest wurde in vorherigen Beiträgen mehrfach beschrieben. Teilweise mit Fotos, Links, Bezugsquellen, Verdrahtungsplänen. Du brauchst Dir nur die Informationen vom Buffet=Beiträge nehmen.
vielleicht kann mir einer helfen ich hab seit gestern einen d1 mini mit dem funkmodul laufen soweit funktioniert alles gut, webseite läuft und die daten kommen auch beim iobroker an. nur leider ist der d1 mini immer wieder im netzwerk nicht mehr erreichbar ping bricht ab. ich hab noch einige andere d1 mini laufen wodurch ich ein wlan problem ausschließe was könnte da sein? version hab ich die 0.4.20
tom schrieb: > nur leider ist der d1 mini immer wieder im netzwerk nicht mehr > erreichbar > ping bricht ab. Das Problem ist bekannt: https://github.com/grindylow/ahoy/issues/83 Die Stabilität des Systems ist bei den Verwendern sehr unterschiedlich. Versucht werden kann: - Anderes Netzteil/Kabel, - Elko über +/GND des nRF24L01+, - das Abfrageintervall auf 30 s einstellen.
Daniel R. schrieb: Marcel A. schrieb: >> Was du gesendet hast, würde mich auch interessieren, denn ich habe >> bisher noch nicht mal eine Antwort bekommen und das was du da geschickt >> hast ... darauf kann man ja aufbauen und rumspielen. > > [code] > Poll inverter 116174403329 > 2022-07-05 14:35:30.212053 Transmit 21 | 51 74 40 33 29 78 56 34 12 81 > 5a 78 35 61 00 78 30 31 01 00 f8 Hab schon mal drauf hingewiesen: CMD 0x51 hat kein SubCMD 0x81, dann 0x5a etc. oder hab ich etwas übersehen? Dann sehe ich Unixtimestamp drin, Tue Jul 27 2021 21:18:40 GMT+0000 Dieses Polling für HM kann nicht gehen. Set Time/Data geht z.Bsp. so CMD 0x15 mit SubCMD 0x80 und Timestamp: 15 72220200 72220200 80 0B 00 62 09 04 9b 00 00 00 00 00 00 00 00 F2 68 F0 CMD 0x51 hat SubCMD 0x5A5A für Limitierung CMD 0x51 hat SubCMD 0xA5A5 für Diebstahl-lock Und diese funktionieren scheinbar nur mit MI-1500, bisher..
Ziyat T. schrieb: > CMD 0x51 hat SubCMD 0x5A5A für Limitierung > CMD 0x51 hat SubCMD 0xA5A5 für Diebstahl-lock > Und diese funktionieren scheinbar nur mit MI-1500, bisher.. Das ist korrekt! Steht ja auch in der Excel/c-File.
Günter H. schrieb: > tom schrieb: >> nur leider ist der d1 mini immer wieder im netzwerk nicht mehr >> erreichbar >> ping bricht ab. > > Das Problem ist bekannt: https://github.com/grindylow/ahoy/issues/83 > Die Stabilität des Systems ist bei den Verwendern sehr unterschiedlich. > Versucht werden kann: > > Anderes Netzteil/Kabel, > Elko über +/GND des nRF24L01+, > das Abfrageintervall auf 30 s einstellen. Danke für die Infos, werde ich testen. Welcher Elko wäre ideal?
Ich n tom schrieb: >> Anderes Netzteil/Kabel, >> Elko über +/GND des nRF24L01+, >> das Abfrageintervall auf 30 s einstellen. Ich nutze ein Iphone Netzteil. Ohne Elko etc. Elko >= 1000 uF / 10 Volt passt auf jeden Fall. Ein 100 nF zus. parallel kann auch nicht schaden.
:
Bearbeitet durch User
Hier https://github.com/grindylow/ahoy gibt es für das D1 mini-Board die Firmware Version 0.4.22. Das Kompilieren geschieht jetzt über Visual Studio Code/Platformio. Da ich diese Software vor einigen Tagen zum Testen der Firmware für das ESP32-Board installiert hatte, wurde nach Download des "ahoy-main.zip"-Ordners und dem Öffnen der "platformio.ini" mit dem "Platformio: Build"-Befehl (überraschenderweise) erfolgreich eine "firmware.bin" erzeugt. Im Platformio-Explorer findet man den Speicherort der neuen Firmware - ggf. im Windows-Explorer suchen. Mit dieser neuen Firmware habe ich dann von Version 0.4.20 problemlos ein Update auf 0.4.22 gemacht. Was das Update in Richtung Stabilität bringt, kann ich naturgemäß noch nicht sagen. Der Text oben ist von jemandem verfasst, der von Programmieren praktisch null Ahnung hat. Die Default-Verschaltung ab 0.4.20 habe ich mit angehängt.
:
Bearbeitet durch User
Kannst du die neue -.bin auch raufladen? Bei mir funzt das mit platformIO nicht
hab vorhin gerade die 0.4.22 drauf gespielt. die wifi ausfälle sind immer noch, aber was mir aufgefallen ist das der seriele debug print weiter läuft auch wenn der d1 mini per netzwerk nicht mehr erreichbar ist?
Daniel R. schrieb: > Wenn du etwas fertiges haben willst, was man irgendwo kaufen kann... > dann muss du wohl noch etwas warten. Außer jemand hat paar Platinen und > Gehäuse übrig und könnte es für die Community Bereitstellen (gegen eine > kleine Bezahlung?). Das war eigentlich mein Plan. Also eine Platine layouten, fertigen lassen und für die die nicht löten wollen/können würde ich die auch bestücken und alles in eine feines Gehäuse packen um das Ganze dann für Selbstkostenpreis + kleiner Aufwandsentschädigung anzubieten. Nun habe ich die Platine ja schon fertig, und zur Probe mal eine selbst geätzt und bestückt. Leider hat sich herausgestellt das der Empfang sehr viel schlechter ist als mit der Breadboard Version :( Dann habe ich die Schirmung des RF24 entfern, keine Besserung. Dann habe ich das Netzteil entfernt und per USB versorgt, keine Besserung. Dann habe ich den Wemos mit Jumper Kabel von den RF24 entfernt positioniert, keine Besserung. Die Platine unter Lupe natürlich optisch auf Fehler untrsucht, durchgemessen, nix zu finden. Den RF ausgetauscht, keine Besserung. Nun bin ich ratlos, und komme nicht weiter. Irgendwas stört den Empfang bei meinem Aufbau. Auch eine Verlagerung der Antenne mit 3m Verlängerungskabel hat nix gebracht. Ich weiß nicht was ich verändern muss damit es so gut funktioniert wie auf dem Steckbrett. Liegt es irgendwie an der Lage / Nähe des RF24 zum Wemos ? Oder stört die Massefläche der Platine ? Ich komm nicht weiter ...
Holger S. schrieb: > Liegt es irgendwie an der Lage / Nähe des RF24 zum Wemos ? Oder stört > die Massefläche der Platine ? Ich habe mir als purer Anfänger meine Platinen bei Aisler "schnitzen lassen" - funktionieren problemlos ohne Empfangsprobleme. Ich habe den D1 direkt neben dem NRF24l01+ (nicht über) und dachte mir erst "das geht schief" - tut was es soll ohne große Schirmung. Entweder die wirklich "räumliche Nähe" oder die Massefläche
tom schrieb: > hab vorhin gerade die 0.4.22 drauf gespielt. > die wifi ausfälle sind immer noch, aber was mir aufgefallen ist das der > seriele debug print weiter läuft auch wenn der d1 mini per netzwerk > nicht mehr erreichbar ist? kann es sein das die probleme vom webserver kommen? wenn ich ganz oft die webseite aktualisiere fällt die netzwerkverbindung bei mir aus. ist das bei euch auch?
Bei mir ist das Intervall auf 30 s eingestellt. Seit dem Update (vor knapp 4 Std.) stabil.
Rene M. schrieb: > Kannst du die neue -.bin auch raufladen? > Bei mir funzt das mit platformIO nicht Ja die neue Firmware ist mit PlatformIO gebaut. Jetzt gibt es auch eine erste CI (GitHub Actions), die nach dem Commit von Code die Firmware automatisch baut und sogar als Artifakt zum Download zur Verfügung stellt ;-). Wenn ich richtig gelesen habe, bleiben die Artifakte nur 90 Tage, dann werden die automatisch gelöscht. Hier z.B. das von gestern: https://github.com/grindylow/ahoy/actions dann auf den obersten Eintrag klicken, ganz unten erscheint dann das Artifakt
:
Bearbeitet durch User
Günter H. schrieb: > Bei mir ist das Intervall auf 30 s eingestellt. Seit dem Update > (vor > knapp 4 Std.) stabil. das hatte ich auch schon probiert, leider ohne verbesserung, auch mit 60s hab ich probiert
Günter H. schrieb: > Bei mir ist das Intervall auf 30 s eingestellt. Seit dem Update (vor > knapp 4 Std.) stabil.
Holger S. schrieb: > > Nun bin ich ratlos, und komme nicht weiter. Irgendwas stört den Empfang > bei meinem Aufbau. Auch eine Verlagerung der Antenne mit 3m > Verlängerungskabel hat nix gebracht. Ich weiß nicht was ich verändern > muss damit es so gut funktioniert wie auf dem Steckbrett. > Liegt es irgendwie an der Lage / Nähe des RF24 zum Wemos ? Oder stört > die Massefläche der Platine ? > > Ich komm nicht weiter ... Ich denke der Huckepack Aufbau ist das Problem, denn beides funkt mit 2,4Ghz !! Nebeneinander mit Abstand und der Variante ein Blech das man dazwischen einlöten kann. Und den Wemos gleich mit Pigtail für externe Antenne nehmen. Die kurzen Leiterbahnen vom Chip zur Antenne strahlen ja auch schon was aus.
Hallo Holger S., wenn ich mir die Erfahrungen / Kommentare zu Deiner Platine und den Aufbau der Anderen durchlese fällt mir auf, daß nur Du auch den AC/DC Transformator und den Spannungsregler mit auf der Platine hast. Hast Du Dir mal die Spannung am ESP mit einem Oszi angeschaut ? Kannst Du das Netzteil nochmal separat aufbauen auf einem Breadboard und dann mit Leitungen an den Rest der Platine anschließen, dann solltest Du ja sehen ob es einstrahlt und somit Auswirkungen auf den Empfang hat. Sind ja immerhin 50Hz ?
Holger S. schrieb: > Nun bin ich ratlos, und komme nicht weiter. Irgendwas stört den Empfang > bei meinem Aufbau. Ich kann mir gut vorstellen, das beide Antennen die auf 2.4GHz funken sich bisschen stören. Auch wenn Sie auf unterschiedlichen Kanal senden. Trotzdem könnte ich mir das vorstellen. Nimm doch mal den D1 runter und verbinde ihn mit Jumperkabel und platziere denn D1 neben dran. Bringt das etwas? 180° drehen noch? Ok, Richard K. und isnoahoy haben ja auch was dazu geschrieben. :D
:
Bearbeitet durch User
Hallo Holger, hast du schlechten Empfang oder gar keinen Empfang? Mein Fehler war, dass seit 0.4.20 IRQ und CE getauscht wurden. Da ich das kleine nRF24L01+ ohne externe Antenne verwende kann ich nicht sagen ob die Verbindung auf deiner Platine stimmt. Was man auch nicht so gut auf dem Bild sehen kann, ist die Verbindung von GND (am ESP neben den 5V) zum 3,3V Spannungsstabi mittlerer PIN, da sollte doch keine Verbindung sein, da hier doch die 3,3V sind? Das sieht sehr knapp aus. Was du aber auf alle Fälle noch überarbeiten solltest, ist der Abstand zwischen der 230V AC Seite zur Niederspannungsseite. Der 230V AC Bereich sollte eindeutig von der Niederspannungsseite getrennt sein. Wenn ich mich recht erinnere, muss man hier 8mm Abstand einhalten. Am besten den Stabi mit Elko zwischen ESP und Netzteil-Modul positionieren. Evtl. auch das Netzteil um 90 Grad drehen. Und die Sicherung auf der AC Seite nicht vergessen, außer du hast sie in der Netz-Leitung integriert.
Lukas P. schrieb: > Ja die neue Firmware ist mit PlatformIO gebaut. Jetzt gibt es auch eine > erste CI (GitHub Actions), die nach dem Commit von Code die Firmware > automatisch baut und sogar als Artifakt zum Download zur Verfügung > stellt ;-). Wenn ich richtig gelesen habe, bleiben die Artifakte nur 90 > Tage, dann werden die automatisch gelöscht. > > Hier z.B. das von gestern: > https://github.com/grindylow/ahoy/actions > > dann auf den obersten Eintrag klicken, ganz unten erscheint dann das > Artifakt Danke für diesen Hinweis, das ist ein sehr einfacher und schneller Zugang zur aktuellen bin-Datei. Ergänzung: Man muss bei guthub angemeldet sein, um das Artifakt herunterladen zu können.
Holger S. schrieb: > Nun bin ich ratlos, und komme nicht weiter. Irgendwas stört den Empfang > bei meinem Aufbau. Wenn man sich das Layout anguckt fällt mir etwas auf: Der Elko ist völlig nutzlos. Dieser gehört nicht irgendwo auf die Leiterplatte, sondern nach an den NRF24L01+. Die 6mm Abstand (oder Fräsung) zwischen 230V und Niederspannung wurden schon erwähnt. Sind aber nicht die Ursache deines Problems. Wenn du deine Layout datein mit uns teilst können wir noch mehr tipps geben.
Wäre es sinnvoll, den Timestamp der jeweils letzten erfolgreichen Abfrage des WR (zusätzlich zu den bereits vorhandenen Daten) per MQTT mit zu übertragen? Dann könnte man auf einfache Weise erkennen, ob die WR-Daten, die man beim Broker abonniert hat, aktuell sind oder nicht. Oder gibts einen anderen Weg...?
Holger S. schrieb: > Ich weiß nicht was ich verändern > muss damit es so gut funktioniert wie auf dem Steckbrett. Disclaimer: Ich habe weder beruflich noch in der Ausbildung mit Platinen oder Schaltungen zu tun! Hallo Holger, wenn ich das richtig erkannt habe, dann finde ich die GND-Verbindung vom RF24 nicht optimal. Die geht auf den Fotos nur durch das GND-Pad vom Wemos. Ob die Empfangsprobleme damit zu tun haben, könnte man mit einer schnellen Kabelbrücke testen. Und dann wollen doch die meisten LDO auch noch einen Kondensator am Ausgang. Gerade die RF24 scheinen doch relativ empfindlich auf die Restwelligkeit zu reagieren. Hatte ich so zumindest beim Mitlesen für mich rausgeschlossen. Aber beides nur spontane Ideen eines Hobbyisten. Gruß Axel
Ist da GND und 3,3V wirklich getrennt?
Daniel R. schrieb: > Holger S. schrieb: >> Nun bin ich ratlos, und komme nicht weiter. Irgendwas stört den Empfang >> bei meinem Aufbau. > > Ich kann mir gut vorstellen, das beide Antennen die auf 2.4GHz funken > sich bisschen stören. Auch wenn Sie auf unterschiedlichen Kanal senden. > Trotzdem könnte ich mir das vorstellen. > > Nimm doch mal den D1 runter und verbinde ihn mit Jumperkabel und > platziere denn D1 neben dran. Bringt das etwas? 180° drehen noch? > > Ok, Richard K. und isnoahoy haben ja auch was dazu geschrieben. :D Trotz enger Sandwich-Bauweise funkt mein ESP8266 sehr zuverlässig (mit Reboots) mit dem WR. Distanz zum WR ca. 15m. https://www.mikrocontroller.net/attachment/560492/DE6F5772-A240-4F90-AB27-12E40A65CEF2.jpeg
hat schon jemand versucht den webserver mal abzuschalten und schauen ob der d1 mini dann immer noch neustartet?
Peter L. schrieb: > Wäre es sinnvoll, den Timestamp der jeweils letzten erfolgreichen > Abfrage des WR (zusätzlich zu den bereits vorhandenen Daten) per MQTT > mit zu übertragen? > > Dann könnte man auf einfache Weise erkennen, ob die WR-Daten, die man > beim Broker abonniert hat, aktuell sind oder nicht. Oder gibts einen > anderen Weg...? ioBroker hat für jedes Objekt mehrere Timestamps, zB wann es erzeugt wurde und wann es zuletzt aktualisiert wurde. Ich kann mir vorstellen, dass sich andere Systeme hier genauso verhalten und sehe daher keine Notwendigkeit den timestamp extra zu schicken. @Tom: gute Idee, den Versuch sollten wir machen, ich bin aber der festen Überzeugung, dass es an der NRF24 Lib oder deren Bedienung liegt: https://github.com/grindylow/ahoy/issues/83
:
Bearbeitet durch User
Stefan T. schrieb: > Kannst Du das Netzteil nochmal separat aufbauen auf einem Breadboard und > dann mit Leitungen an den Rest der Platine anschließen, dann solltest Du > ja sehen ob es einstrahlt und somit Auswirkungen auf den Empfang hat. > Sind ja immerhin 50Hz ? Zitat aus meinem Post: "Dann habe ich das Netzteil entfernt und per USB versorgt, keine Besserung." Daniel R. schrieb: > Nimm doch mal den D1 runter und verbinde ihn mit Jumperkabel und > platziere denn D1 neben dran. Bringt das etwas? 180° drehen noch? Richard K. schrieb: > Ich denke der Huckepack Aufbau ist das Problem, denn beides funkt mit > 2,4Ghz !! Zitat aus meinem Post: "Dann habe ich den Wemos mit Jumper Kabel von den RF24 entfernt positioniert, keine Besserung." Claus T. schrieb: > hast du schlechten Empfang oder gar keinen Empfang? > Mein Fehler war, dass seit 0.4.20 IRQ und CE getauscht wurden. Da ich > das kleine nRF24L01+ ohne externe Antenne verwende kann ich nicht sagen > ob die Verbindung auf deiner Platine stimmt. > Was man auch nicht so gut auf dem Bild sehen kann, ist die Verbindung > von GND (am ESP neben den 5V) zum 3,3V Spannungsstabi mittlerer PIN, da > sollte doch keine Verbindung sein, da hier doch die 3,3V sind? Das sieht > sehr knapp aus. > Was du aber auf alle Fälle noch überarbeiten solltest, ist der Abstand > zwischen der 230V AC Seite zur Niederspannungsseite. Der Empfang ist da, aber es werde sehr viele Fails erzeugt und von den 6 Invertern sind meist nur 2 available. Die Leiterbahnen sind OK. Das ist schlecht zu fotografieren. Aber unter der Lupenlampe nochmal gecheckt und durchgemessen hatte ich das ja auch. Das hätte auch gleich smoke gegen wenn da ne Verbindung ist. Der Aufbau funktioniert ja auch, nur der Empfang taugt nix. Den Abstand 230V werde ich noch vergrößern. Wahrscheinlich lasse ich das on Board Netzteil wohl auch weg. Ich dachte es wäre ne gute Idee, aber wenn ich den Wemos und den RF24 nebeneinander setzten muß, und die Abstände vergrößern soll, wird mir das ganze schon wieder zu groß und muß in ein anderes Gehäuse. Dann eben nicht kompakt und mit extra USB Nezteil. Peter L. schrieb: > Trotz enger Sandwich-Bauweise funkt mein ESP8266 sehr zuverlässig (mit > Reboots) mit dem WR. Distanz zum WR ca. 15m. Tja, deshalb bin ich ja so Ratlos.
Dear All, At first let me express my respect to all who contributes to this topic. I am follwing this thread since a while and I am using the pre-compiled version 0.4.19 on a Wemos D1 mini clone anf HM-800 inverter and Home Assistant. The pre-compiled image works for me only when I use pins D2/D1 instead of D4/D3 for signal CE/IRQ. Hello Marcel, I am trying to compile your ESPhome version on a 8266 (Wemos D1 mini clone) ESPHome version: 2022.5.1 I am facing with an issue defining the serial number of the inverter. If I set the serial number as a hex number ( 12 digit decimal number converted to hex) like in your example file:
1 | serialnumber: "0x1234567890" |
then the ESPhome enters to a boot loop with the following output on the console:
1 | [C][api:025]: Setting up Home Assistant API server... |
2 | [D][hoymiles.esp32:046]: Setting up Hoymiles Component |
3 | E: inverter type can't be detected! |
4 | [I][hoymiles.esp32:065]: Adding Inverter: hm800 ( 0x0 ) |
5 | I: RF24 Amp Pwr: RF24_PA_I: LOW |
6 | I: Radio Config: |
7 | SPI Frequency = 1 Mhz |
8 | Channel = 3 (~ 2403 MHz) |
9 | RF Data Rate = 250 KBPS |
10 | RF Power Amplifier = PA_LOW |
11 | RF Low Noise Amplifier = Enabled |
12 | CRC Length = 16 bits |
13 | Address Length = 5 bytes |
14 | Static Payload Length = 32 bytes |
15 | Auto Retry Delay = 250 microseconds |
16 | Auto Retry Attempts = 0 maximum |
17 | Packets lost on |
18 | current channel = 0 |
19 | Retry attempts made for |
20 | last transmission = 15 |
21 | Multicast = Disabled |
22 | Custom ACK Payload = Disabled |
23 | Dynamic Payloads = Enabled |
24 | Auto Acknowledgment = Disabled |
25 | Primary Mode = RX |
26 | TX address = 0xdeadbeef01 |
27 | pipe 0 (closed) bound = 0xdeadbeef01 |
28 | pipe 1 ( open ) bound = 0x1234567801 |
29 | pipe 2 (closed) bound = 0xc3 |
30 | pipe 3 (closed) bound = 0xc4 |
31 | pipe 4 (closed) bound = 0xc5 |
32 | pipe 5 (closed) bound = 0xc6 |
33 | [I][hoymiles.sensor:010]: Sensor hm800, ▒H#@ |
34 | [I][app:062]: setup() finished successfully! |
If I set it as a decimal number (as it is printed on the HW, either with or without quotes):
1 | serialnumber: "114180445566" |
then it does not enter the boot loop, but prints the following:
1 | [D][hoymiles.esp32:046]: Setting up Hoymiles Component |
2 | E: inverter type can't be detected! |
3 | [I][hoymiles.esp32:065]: Adding Inverter: hm800 ( 0x7fffffff ) |
4 | I: RF24 Amp Pwr: RF24_PA_I: LOW |
5 | I: Radio Config: |
6 | SPI Frequency = 1 Mhz |
7 | Channel = 3 (~ 2403 MHz) |
8 | RF Data Rate = 250 KBPS |
9 | RF Power Amplifier = PA_LOW |
10 | RF Low Noise Amplifier = Enabled |
11 | CRC Length = 16 bits |
12 | Address Length = 5 bytes |
13 | Static Payload Length = 32 bytes |
14 | Auto Retry Delay = 250 microseconds |
15 | Auto Retry Attempts = 0 maximum |
16 | Packets lost on |
17 | current channel = 0 |
18 | Retry attempts made for |
19 | last transmission = 15 |
20 | Multicast = Disabled |
21 | Custom ACK Payload = Disabled |
22 | Dynamic Payloads = Enabled |
23 | Auto Acknowledgment = Disabled |
24 | Primary Mode = RX |
25 | TX address = 0xdeadbeef01 |
26 | pipe 0 (closed) bound = 0xdeadbeef01 |
27 | pipe 1 ( open ) bound = 0x1234567801 |
28 | pipe 2 (closed) bound = 0xc3 |
29 | pipe 3 (closed) bound = 0xc4 |
30 | pipe 4 (closed) bound = 0xc5 |
31 | pipe 5 (closed) bound = 0xc6 |
32 | [I][hoymiles.sensor:010]: Sensor hm800, ▒H#@ |
33 | [I][app:062]: setup() finished successfully! |
What am I doing wrong?
Beitrag #7121184 wurde vom Autor gelöscht.
Zsolt Z. schrieb:
Hello Zsolt, you can try this. I don´t know if it is working so.
Example (see hmRadio.h)
// Serial WR : 1141 74 11 22 33 Label on Inverter
try
// #define WR1_RADIO_ID ((uint64_t)0x 33 22 11 74 01ULL)
only for better readable for your eyes
// #define WR1_RADIO_ID ((uint64_t)0x 74 11 22 33 01ULL)
only for better readable for your eyes
(see hmRadio.h)
// in Source Code
#define WR_RADIO_ID ((uint64_t)0x3322117401ULL)
// OR try
#define WR_RADIO_ID ((uint64_t)0x7411223301ULL)
You have to change the example to YOUR serial number.
:
Bearbeitet durch User
Holger S. schrieb: > Stefan T. schrieb: > Daniel R. schrieb: > Richard K. schrieb: > Claus T. schrieb: > Peter L. schrieb: > Tja, deshalb bin ich ja so Ratlos. Hallo Ich hatte lange auch ab und zu den ganzen Tag Empfang Probleme mit Wemos, ich verwende meine spez. SW-Version auf Hubi's Basis. Ich habe es lange gemessen und gesnifft, das Problem war nicht die HW ! (Edit: ich dachte auch mal die NRF sind futsch..) - Ich würde mal die SW ohne Interrupt mit polling und ohne CRC ausprobieren. Ich bin ziemlich sicher, dass mit Interrupt etwas verloren geht, warum weiss ich nicht. Mit CRC geht vieles auch verloren. Ohne CRC sind die Werte fast 97% richtig, die Falschen kann man ausfiltern. - Ich bin auch ziemlich sicher, dass die WR's nicht immer auf CH3 senden, die SW muss beim RX auch hoppen. Mein MI-1500 sendet manchmal einen Tag lang nur über CH61/CH75. Wenn die SW nur auf CH3 hört, siehst du den ganzen Tag nichts! Edit: versucht mal mit einer NRF24 Sniffer SW ob ihr mit der Dose etwas empfaengt?
:
Bearbeitet durch User
Hallo Zusammen, erstmal vielen Dank für die tolle Arbeit hier. Mein Setup: - DTU-Lite - HM1500 - 4 Module - HM800 - 2 Module - weitere 4 HM1500 kommen noch dazu An meinem DTU-Lite habe ich über die Cloud alles verbunden mit dem HM1500. Leider kann der DTU ja nur 4 Module, deshalb bin ich jetzt auf die 8266/RF24 Lösung gestoßen und habe dieses gleich umgesetzt. Bisher läuft dieses, aber wenn ich den DTU-Lite und den 8266 am laufen haben, dann erhalte ich vom HM1500 oft keine Daten. Der HmM800 hat diese Probleme nicht. Nun ist meine Vermutung das der HM1500 ja mit der Cloud am DTU-Lite hängt und dadurch irgend welche Daten verloren gehen. Kann ich dieses irgendwie umgehen? Hat noch jemand dieses Problem? Vielen Dank Gruß
Denny S. schrieb: > - DTU-Lite > - HM1500 - 4 Module > - HM800 - 2 Module ... > Kann ich dieses irgendwie umgehen? Hat noch jemand dieses Problem? Du kannst ja auch nicht 2 PKWs gleichzeitig fahren :-) Vermutlich hat der HM1500 Probleme mit 2 DTUs zu kommunizieren ? 1. Möglichkeit: DTU-Lite Stromversorgung kappen - also aus das Teil 2. Möglichkeit: dem 8266 in der Software die gleiche SN geben (see hmRadio.h) wie der DTU-Lite und neu übersetzen und in den 8266 laden und dann schauen, ob das dann funktioniert. Wenn ich nix überlesen habe, hat das wohl noch niemand probiert. Also zack und los :-) Du darfst als Erster :-) Bin selbst gespannt. Viel Erfolg !
Variante 1 geht, aber ich würde gerne beides nutzen. Eine DTU-Pro habe ich schon geordert, damit ich in Zukunft alle HM's auslesen kann. Wieviele HM's kann der 8266 mit AHOY gleichzeitig lesen? Hat das jemand mal getestet? Variante 2 hatte ich schon probiert, aber dann bekomme ich überhaupt keine Daten mehr. Kann aber auch sein das ich mit der Seriennummer was falsch gemacht habe. Diese beginnt mit: 10D98015XXXX Muss ich diese 1zu1 in die Zeile kopieren? #define DTU_RADIO_ID ((uint64_t)0x1234567801ULL) Danke
schau heute um 10:25. Da hab ich geschrieben wie die SN einzutragen ist. Die letzten 4 Zahlenpaare der SN. Musst einfach Beides mal probieren. Die Anzahl der WR kannst Du auch irgendwo konfigurieren vor dem Übersetzen.
:
Bearbeitet durch User
Herbert K. schrieb: > 2. Möglichkeit: dem 8266 in der Software die gleiche SN geben (see > hmRadio.h) wie der DTU-Lite und neu übersetzen und in den 8266 laden und > dann schauen, ob das dann funktioniert. So hab ich die DTU-Pro<>MI-1500 gesnifft, schon am Anfang des Projekts. Wenn du die gleiche Adresse eingibst wie die DTU, kannst alles mithören was der WR sendet.
Denny S. schrieb: > Nun ist meine Vermutung das der HM1500 ja mit der Cloud am DTU-Lite > hängt und dadurch irgend welche Daten verloren gehen. Der WR hat keine Ahnung von der Cloud, nur die DTU haengt an der. Zum parallel Betrieb, siehe Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
tom schrieb: > hat schon jemand versucht den webserver mal abzuschalten und schauen ob > der d1 mini dann immer noch neustartet? Lukas P. (lumapu) schrieb: > @Tom: gute Idee, den Versuch sollten wir machen, ich bin aber der festen > Überzeugung, dass es an der NRF24 Lib oder deren Bedienung liegt: > https://github.com/grindylow/ahoy/issues/83 Ich persönlich glaube, daß die von Tomas B genutzte AsyncWebServer Bibliothek evtl. auch das Problem behebn könnte. Momentan verwenden wir die ESP8266WebServer Library und die blockiert bis die Seite ausgeliefert wurde. Ich habe keine Ahnung wie die AsyncWebServer Bibliothek es genau macht, aber anscheinend kann diese mehrere Requests parallel beantworten und hat dazu so eine Art "Multithreading". Zumindest wird der Listener immer gleich wieder freigegeben und steht dann für weitere Verbindungen zur Verfügung. Vielleicht eine Funktion der AsyncTCP Bibliothek die als Abhängigkeit dazu kommt. @Thomas B., wäre es denkbar die AsyncWebServer Bibliothek im ESP8266 Code zu verwenden bzw. könnte man auch Deinen OpenDTU Code für den ESP8266 übersetzen ?
Stefan T. schrieb: > @Thomas B., wäre es denkbar die AsyncWebServer Bibliothek im ESP8266 > Code zu verwenden bzw. könnte man auch Deinen OpenDTU Code für den > ESP8266 übersetzen ? ESPAsyncWebServer läuft auch unter ESP8266. OpenDTU Code für ESP8266 ist so out of the Box wohl nicht möglich, da ich diverse Compiler und Linker Features verwende die im Toolkit vom 8266 nicht vorhanden sind.
Denny S. schrieb: > Nun ist meine Vermutung das der HM1500 ja mit der Cloud am DTU-Lite > hängt und dadurch irgend welche Daten verloren gehen. Moin, ich habe einen HM-1500 und frage ihn alle 10s mit ESP8266 und ESP32 ab, unterschiedliche DTU-ID's, keine Probleme. Dem WR ist es eigentlich egal, er antwortet stumpf. Das was ich mir vorstellen kann, das er Probleme hat mit unterschiedlichen Zeitframes, die er bekommt oder die Abfragen zu schnell nacheinander kommen. Bei meine TSUN-DTU sehe ich im Sekundentakt abfragen, vielleicht kollidiert es da, HM und TSUN sind ja quasi identisch. Kannst du einfach mal deine DTU für ein paar Minuten trennen und schauen, ob es dann geht?
Hallo, ja wenn der DTU aus ist, gehen keine Daten verloren. Ist der DTU an, sieht man gut das nur der HM1500 hin und wieder keine Daten erhält (hängt am DTU), aber der HM800 (nur über AHOY) immer alles korrekt ist. Das mit der DTU Seriennummer ändern im AHOY habe ich auch probiert, aber dann geht nix mehr. Vielleicht geht das mit der DTU-Pro dann besser.
Thomas B. schrieb: >> könnte man auch Deinen OpenDTU Code für den ESP8266 übersetzen ? > ESPAsyncWebServer läuft auch unter ESP8266. OpenDTU Code für ESP8266 ist so out of the Box wohl nicht möglich, da ich diverse Compiler und Linker Features verwende die im Toolkit vom 8266 nicht vorhanden sind. Hallo Thomas, das habe ich gesehen vor allem das std::bind() für die Interrupt Handler will er bei mir partout nicht übersetzen. Ich habe es aber auch nicht hinbekommen die Interrupthandler außerhalb der Klassenbzu definieren. Das scheint dem ESP8266 Cross Compiler nicht zu gefallen. Das andere sind glaube ich div. Datentypen die beim ESP8266 etwas anders sind. Soll ich Dir die bereits gemachten Anpassungen irgendwie per PR zukommen lassen ?
Hallo Denny S., ich glaube auch die DTU Pro sieht es nicht gerne wenn Du einzelne WR sowohl bei der DTU Lite und bei der Pro registrierst und abfragst. Wenn Du das Abfrageintervall auf einen größeren Zeitraum stellst könnte es evtl klappen aber mE bringst Du damit die Payload Decodierung aus dem Tritt, weil er ja per Interrupt Pakete bekommt die er evtl grade gar nicht erwartet. Im DTU Code von Hoymiles sind zwar einige Bedingungen für falsche Pakete (out-of-order) definiert die dann ggf. einen Abbruch der Verbindung und ein sog. NET_INIT (ich glaube unser Zeit senden Paket) auslösen. Aber auch im Ahoy-ESP8266 code schon alle Eventualitäten berücksichtigt sind wage ich zu bezweifeln. Der Hoymiles Code wartet auch max 300-500ms auf eine Antwort, da gibt es eine ausführliche Methode die für jede Anfrage die sog LOCAL_TIME berechnet bevor die Anfrage bzw Antwort verworfen wird und eine neue Anfrage gestellt wird. Interessehalber was ist die Idee dabei DTU (Lite/Pro) parallel zum Ahoy-ESP zu betreiben ? Welche Funktionalität brauchst Du noch damit Du die DTU ersetzen kannst ?
@Lukas evtl könnten wir ein sog Promiscuous Feature in die AHOY-ESP Software einbauen, bei dem er selbst keine Anfragen sendet aber ankommende Payloads versucht zu dekodieren ? Wäre ein Flag in den Settings je WR und er müsste halt sehen ob er irgendwann das erste Antwort-Paket und alle folgenden mitbekommt. Wenn es nicht klappt kann er die Payload ja auch wieder verwerfen, da er ja kein Retransmit senden kann/soll.
IsnoAhoy schrieb: > ich glaube auch die DTU Pro sieht es nicht gerne wenn Du einzelne WR > sowohl bei der DTU Lite und bei der Pro registrierst und abfragst. Wenn Auf der smiles-cloud kann man einen WR nur 1x registireren, DTU-lite oder DTU-Pro > Interessehalber was ist die Idee dabei DTU (Lite/Pro) parallel zum > Ahoy-ESP zu betreiben ? > Welche Funktionalität brauchst Du noch damit Du die DTU ersetzen kannst > ? DTU-Lite kann nur 4 Module haendeln, ich denke er möchte mehr sehen...
Hallo @All, Lukas und ich diskutieren gerade in https://github.com/grindylow/ahoy/issues/36 und #83 ob wir einen ESP8266 mit 4MB Flash vorraussetzen können und sollen. Die HTML-Seiten und Konfiguration scheint langsam den Flash zu füllen und die Wemos D1 mini ***LITE v1*** mit nur 1MB und einem ESP-07 würde damit als ***unsupported*** rausfallen. Wieviele von Euch nutzen den ESP-07 bzw. einen Wemos D1 mini in der ***LITE v1*** mit nur einem 1MB Flash ? Bitte im o.g. Github issue #36 und/oder #83 melden, damit wir die Auswirkung dieser Änderung abschätzen können. Danke!
@Ziyat T., danke für den Hinweis es scheint sich in #91 heraus zu kristallisieren, daß wir alle Antwort-Pakete ( egal für welche DTU ) die wir empfangen auch versuchen in die Payloadstruktur zu integrieren. Wir sollten hier also einen Plausibilitätscheck der DTU Addresse einbauen, außer wir sind im o.g. Promiscuous Mode. Sonst kommen wir mit den Antworten für die echte DTU und denen auf unsere Anfragen durcheinander. Siehe https://github.com/grindylow/ahoy/issues/91 @Denny S., ich verstehe trotzdem nicht warum Du die ESP Software und eine original DTU (Lite/Pro) verwenden willst ? Was fehlt Dir noch was die DTU kann und unsere Software (noch) nicht ?
> @Denny S., ich verstehe trotzdem nicht warum Du die ESP Software und > eine original DTU (Lite/Pro) verwenden willst ? > Was fehlt Dir noch was die DTU kann und unsere Software (noch) nicht ? Limitieren eines HoyMiles geht noch immer nicht :(
Moin Zusammen, IsnoAhoy schrieb: > Hallo Denny S., > ich glaube auch die DTU Pro sieht es nicht gerne wenn Du einzelne WR > Interessehalber was ist die Idee dabei DTU (Lite/Pro) parallel zum > Ahoy-ESP zu betreiben ? Eigentlich erstmal nur Testweise. Ich möchte alle Werte aus der Anlage gerne in ioBroker haben. Das geht mit dem DTU-Lite leider überhaupt nicht, deshalb hatte ich mir einen DTU-Pro + Energiemesser bestellt (kommt aber erst Ende Juli). Dann bin ich auf dieses Projekt gestoßen. Ohne DTU-Lite am Netz könnte ich eigentlich auf AHOY umstellen, aber dann geht mir aktuell die Aufbereitung der Daten in der Hoymiles Cloud flöten. > Welche Funktionalität brauchst Du noch damit Du die DTU ersetzen kannst > ? Also wenn ich schon so gefragt werde :-) Was haltet ihr von einer Berechnung der Gesamtwerte der Anlage, also wenn mehrere WR eingebunden sind und die Daten ebenfalls gleich über MQTT raus schicken? Weitere Punkte fallen mir bestimmt noch ein. :-) Gruß
Dieser Thread ist ja damit gestartet das man versucht die Daten von Hoymiles auszulesen. Das ist ja eigentlich geschafft und dieser Thread wird ja mehr und mehr zum Support Thread mit sehr vielen gleichen Fragen und langer ladezeit. Wollen wir ggf. einen neuen Thread aufmachen, wo dann über die Raw daten gesprochen wird und wieder, wie am Anfang, Payloads und Protokoll diskussion entstehen? Ich habe leider keine DTU und kann somit auch keine Daten sniffen. Ich kann aber programmieren und kann helfen Sachen zu testen. Wie man ja oben schon sieht, ich bin wirklich an der Limitierung interessiert. Danke Marcel
:
Bearbeitet durch User
Hi Marcel, geht uns doch allen so. :) - Discord Link weiter oben. Ich probiere viel alleine aus. Aber neue Erkentniss habe ich nicht. Eine DTU-pro wäre hier Hilfreich. Gruß Daniel
Marcel A. schrieb: > Dieser Thread ist ja damit gestartet das man versucht die Daten von > Hoymiles auszulesen. Das ist ja eigentlich geschafft Ist meines Erachtens noch nicht geschafft bzw. nur zum Teil. Wir bekommen zwar die "Guten Daten" aber nicht die Bösen, sofern ich nix übersehen habe. Es ist noch gar nix in Richtung Fehler Abfrage erschnüffelt bei der "C" Programmierung. Ich habe nur im python Source eine Fehlerliste entdeckt. > Wollen wir ggf. einen neuen Thread aufmachen, wo dann über die Raw daten > gesprochen wird und wieder, wie am Anfang, Payloads und Protokoll > diskussion entstehen? Ich bin sehr dafür. Darum hatte ich ja auch schon für HMT, HMS, DTU-Pro-S extra Threads angelegt in der Hoffnung, das sich da auch mal irgendwann jemand einfindet und nicht diesen hier wiederholt kapert. Mit Discord kann ich nix anfangen. Sagt mir nix. Wenn, dann Bitte hier. Nur mir fällt kein Name ein. Vielleicht so? Protokoll Analyse Hoymiles HM-xxxx, MI-xxxx Bits und Bytes Und als 1. Beitrag so was in der Art wie ich bei HMT geschrieben habe evt. Sinngemäß: Kein Support für Entwicklungsumgebungen (kann Source nicht übersetzen usw.) Kein Support zum Flashen der Mikrokontroller Kein Support für MQTT Probleme usw. Dazu bitte den alten Beitrag benutzen: Beitrag "Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" Hier soll nur über die Analyse der Bits und Bytes diskutiert werden
:
Bearbeitet durch User
Hallo Marcel A. & Herbert K., >> Dieser Thread ist ja damit gestartet das man versucht die Daten von >> Hoymiles auszulesen. Das ist ja eigentlich geschafft > Es ist noch gar nix in Richtung Fehler Abfrage erschnüffelt bei der "C" Programmierung. Ich habe nur im python Source eine Fehlerliste entdeckt. Ich finde den Punkt gut hier im ESP evtl. auch die Fehlerliste abzufragen. Das wäre dann eine neue sendEventLog Routine und dann der entsprechende Payload Decoder. Daniel R., hatte ja schon versucht aufgrund der Hoymiles Code Analyse einige Power Limit Kommandos o.a. an seinen Wechselrichter zu schicken. Ich habe bei mir irgendwo die vier NRF24 Module verlegt und somit nur eines am ESP welches ich aber nicht so flexibel einsetzen kann wie das mit dem Raspberry Pi code von Jan-Jonas geht. Ich hatte m.W. auch schon weiter oben die verschiedenen SubCmds und Events aus dem Hoymiles DTU-Pro code (iotloves) extrahiert: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" The current implementation we use for HM-inverters seems to be in the Method `UsartNrf3_Send_PackDataCommand` in `usart_nrf3.c` or `usart_nrf3.h`. There also the user data starts with `0x80` in `byte[10]` and after that the Sub Command mentioned in the Excel sheet. According to the implementation in `usart_nrf3.h` the Sub Command is defined as `DataType` in `usart_nrf3.h`:
1 | typedef enum |
2 | { |
3 | InverterDevInform_Simple = 0, // 0x00 |
4 | InverterDevInform_All = 1, // 0x01 |
5 | GridOnProFilePara = 2, // 0x02 |
6 | HardWareConfig = 3, // 0x03 |
7 | SimpleCalibrationPara = 4, // 0x04 |
8 | SystemConfigPara = 5, // 0x05 |
9 | RealTimeRunData_Debug = 11, // 0x0B |
10 | RealTimeRunData_Reality = 12, // 0x0C |
11 | RealTimeRunData_A_Phase = 13, // 0x0D |
12 | RealTimeRunData_B_Phase = 14, // 0x0E |
13 | RealTimeRunData_C_Phase = 15, // 0x0F |
14 | //RealTimeRunData_Password = 16, // 0x10 |
15 | AlarmData = 17, // 0x11 |
16 | RecordData = 18, // 0x12 |
17 | InternalData = 19, // 0x13 |
18 | ExternalData = 20, // 0x14 |
19 | } DataType; |
Especially the 0x0B rings a bell with me and the traces so far! According to `usart_nrf3.h` DEVCONTROL_ALL is defined as `0x51`:
1 | #define DEVCONTROL_ALL 0x51 |
2 | #define ANSWER_DEVCONTROL_ALL (DEVCONTROL_ALL|0X80) |
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" The main routine is in `UsartNrf3_Send_NetCmdToNrfCmd` where all the commands and subcommands are defined, where the Sub Commands are of `DevControlType`:
1 | typedef enum |
2 | { |
3 | Type_TurnOn = 0, // 0x00 |
4 | Type_TurnOff = 1, // 0x01 |
5 | Type_Restart = 2, // 0x02 |
6 | Type_Lock = 3, // 0x03 |
7 | Type_Unlock = 4, // 0x04 |
8 | Type_ActivePowerContr = 11, // 0x0B |
9 | Type_ReactivePowerContr = 12, // 0x0C |
10 | Type_PFSet = 13, // 0x0D |
11 | Type_CleanState_LockAndAlarm = 20, // 0x14 |
12 | Type_Init = 0xff, // 0xFF |
13 | } DevControlType; |
The AlarmDataType can store up to 20 Alerts as far as I could tell from the `UsartNrf3_Process_DevInform_Alarm` method. Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" Bei den bereits analysierten und implementierten Anfragen an die HM-XXXX Inverter verwendet der Hersteller das REQ_ARW_DAT_ALL 0x15 Kommando und erwartet als Antwort ebenfalls das Komplement ANSWER_REQ_ARW_DAT_ALL (REQ_ARW_DAT_ALL|0X80) also 0x95. Für 0x15 sind die entsprechenden SubCmd's definiert als:
1 | typedef enum |
2 | { |
3 | InverterDevInform_Simple = 0, |
4 | InverterDevInform_All = 1, |
5 | GridOnProFilePara = 2, |
6 | HardWareConfig = 3, |
7 | SimpleCalibrationPara = 4, |
8 | SystemConfigPara = 5, |
9 | RealTimeRunData_Debug = 11, // 0x0B |
10 | RealTimeRunData_Reality = 12, // 0x0C |
11 | RealTimeRunData_A_Phase = 13, // 0x0D |
12 | RealTimeRunData_B_Phase = 14, // 0x0E |
13 | RealTimeRunData_C_Phase = 15, // 0x0F //�澯����-����δ���澯 |
14 | AlarmData = 17, // 0x11 //�澯����-ȫ������澯 |
15 | AlarmUpdate = 18, // 0x12 |
16 | RecordData = 19, // 0x13 |
17 | InternalData = 20, // 0x14 |
18 | GetLossRate = 21, // 0x15 |
19 | //dong 2020-06-15 |
20 | GetSelfCheckState = 30, // 0x1E |
21 | InitDataState = 0xff, |
22 | } DataType; |
Hiervon verwenden wir bisher RealTimeRunData_Debug 0x0B um Daten zum Wechselrichter und seinen Ein- & Ausgängen abzufragen und Jan-Jonas S. hatte vor zwei/drei Wochen begonnen sich die AlarmData 0x11 bzw AlarmUpdate 0x12 anzusehen und dabei einige Status Events aus dem Wechselrichter "Logfile" abrufen können. Hier hatten wir ein Byte weiter hinten beobachtet das wir als Anzahl der "Logmeldungen" identifiziert hatten. Interessant ist hier vor allem auch der InitDataState 0xff den der Hoymiles immer wieder sendet um den Wechselrichter in einen definierten Zustand zu bringen. D.h. wenn eines der Kommandos keine richtige Antwort ergibt, wird ein NET_INIT ausgelöst, der das InitDataState schickt. @Daniel R., Vielleicht ist das ja auch das fehlende Glied um z.B. die Power Limit Funktion zu nutzen ?
Ach ja, wir haben auch schon seit längerem zwei Feature Requests im Github, wenn ihr das lieber nehmen wollt um spezifische Protokoll-Kommandos im Detail zu besprechen: Das hier ist m.E. für die Alarm Data / Update Daten: Use the 0x15 or 0x09 command to query the inverters internal history #77 https://github.com/grindylow/ahoy/issues/77 und das hier sollte das Power Limit behandeln: Feature Erweiterung: Leistungslimitierung (für z.B. geregelter Batteriewechselrichter oder um gesetzliche Grenzen einzuhalten) #31 https://github.com/grindylow/ahoy/issues/31
Herbert K. schrieb:
> Hier soll nur über die Analyse der Bits und Bytes diskutiert werden
Aus meiner Sicht sollten wir es lassen wie es ist:
1. Auch Fragen außerhalb von Bits und Bytes bringen das Projekt
insgesamt weiter,
2. gelingt eine solche "Sortierung" überhaupt (in den neu angelegten
Threads ist bisher kein weiterer Eintrag),
3. die angesprochenen langen Ladezeiten sind bei Auswahl der
Seitentrennung kein Thema.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.