tbnobody
commented
9 months ago Red means indeed no connection. But the last connected time was 16:13... maybe your solar panels don't get no light anymore? in this case the inverter is just off...
Open raebo opened 9 months ago
tbnobody
commented
9 months ago Red means indeed no connection. But the last connected time was 16:13... maybe your solar panels don't get no light anymore? in this case the inverter is just off...
raebo
commented
9 months ago Ok, you're right. That was one reason. It was dark here at that time of night.
I also cleared the panels of snow, restarted the DTU but it still not received any information.
But NTP settings shows:
Hmm, maybe it is to cold for the inverter, currently we have zero degrees outside.
tbnobody
commented
9 months ago The eventlog is received from the inverter. That means that you are receiving something! What shows the home view now?
tictrick
commented
9 months ago Are you using more than one DTU? I ask because the TimeSync messages in the log have strange end times.
raebo
commented
9 months ago Are you using more than one DTU? I ask because the TimeSync messages in the log have strange end times. Until yesterday I've had two hoymiles DTUs online
But now only the Opendtu is online.
And here is the home view again:
Here are some more log messages:
13:02:25.363 > Fetch inverter: 116484660502 13:02:25.363 > Request SystemConfigPara 13:02:25.398 > TX ChannelChangeCommand 868.00 MHz --> 56 84 66 05 02 80 15 16 00 02 15 21 14 14 06 13:02:25.409 > RX Period End 13:02:25.409 > All missing 13:02:25.409 > Nothing received, resend count exeeded 13:02:25.456 > TX RealTimeRunData 865.00 MHz --> 15 84 66 05 02 80 15 16 00 80 0B 00 65 70 62 D1 00 00 00 00 00 00 00 00 A6 B5 4D 13:02:25.494 > RX Period End 13:02:25.494 > All missing 13:02:25.494 > Nothing received, resend whole request 13:02:25.494 > TX AlarmData Channel: 75 --> 15 91 02 77 70 80 15 16 00 80 11 00 65 70 62 CC 00 00 00 00 00 00 00 00 2C 3B 3F 13:02:26.004 > RX Period End 13:02:26.004 > All missing 13:02:26.004 > Nothing received, resend whole request 13:02:26.004 > TX RealTimeRunData 865.00 MHz --> 15 84 66 05 02 80 15 16 00 80 0B 00 65 70 62 D1 00 00 00 00 00 00 00 00 A6 B5 4D 13:02:26.287 > RX Period End 13:02:26.287 > All missing 13:02:26.287 > Nothing received, resend whole request 13:02:26.287 > TX AlarmData Channel: 3 --> 15 91 02 77 70 80 15 16 00 80 11 00 65 70 62 CC 00 00 00 00 00 00 00 00 2C 3B 3F 13:02:26.542 > RX Period End 13:02:26.542 > All missing 13:02:26.542 > Nothing received, resend whole request 13:02:26.542 > TX RealTimeRunData 865.00 MHz --> 15 84 66 05 02 80 15 16 00 80 0B 00 65 70 62 D1 00 00 00 00 00 00 00 00 A6 B5 4D 13:02:27.038 > RX Period End 13:02:27.038 > All missing 13:02:27.038 > Nothing received, resend count exeeded 13:02:27.126 > TX SystemConfigPara Channel: 23 --> 15 91 02 77 70 80 15 16 00 80 05 00 65 70 62 CC 00 00 00 00 00 00 00 00 38 2F 2B 13:02:27.126 > RX Period End 13:02:27.126 > All missing 13:02:27.126 > Nothing received, resend whole request 13:02:27.126 > TX RealTimeRunData 865.00 MHz --> 15 84 66 05 02 80 15 16 00 80 0B 00 65 70 62 D1 00 00 00 00 00 00 00 00 A6 B5 4D 13:02:27.324 > RX Period End 13:02:27.324 > All missing 13:02:27.324 > Nothing received, resend whole request 13:02:27.324 > TX SystemConfigPara Channel: 40 --> 15 91 02 77 70 80 15 16 00 80 05 00 65 70 62 CC 00 00 00 00 00 00 00 00 38 2F 2B 13:02:27.556 > RX Period End 13:02:27.556 > All missing
tbnobody
commented
9 months ago But now only the Opendtu is online.
I this case I assume you are using two DTU's? That not possible due to different frequency jumping algorithm etc. If you now turned of one of your DTUs you have to wait at least 15min until the inverter falls back to it's default frequency and the frequency sync can happen again.
And are we talking about problems with an HM-1500 or an HMS-1600-4T? Seems you are mixing up screenshots here.
stefan123t
commented
9 months ago Regarding the HMS-1600-4T are you using an European version of this inverter ? There have been reports that the North American / US version of this inverter may need some special attention regarding the different Frequency ranges for the CMT2300A radio communication, i.e. center frequency being 915MHz in America instead of 865 MHz here in Europe.
raebo
commented
9 months ago But now only the Opendtu is online.
I this case I assume you are using two DTU's? That not possible due to different frequency jumping algorithm etc. If you now turned of one of your DTUs you have to wait at least 15min until the inverter falls back to it's default frequency and the frequency sync can happen again.
I've stopped the Hoymiles DTUs and now the OpenDTU is the only DTU online. But I still get the error. As it is dark now outside I will check tomorrow again.
And are we talking about problems with an HM-1500 or an HMS-1600-4T? Seems you are mixing up screenshots here.
I have two HM inverters one HM-1500 and a HMS-1600-4T. Both are connected with the DTU. And both gives me some headaches
raebo
commented
9 months ago Regarding the HMS-1600-4T are you using an European version of this inverter ? There have been reports that the North American / US version of this inverter may need some special attention regarding the different Frequency ranges for the CMT2300A radio communication, i.e. center frequency being 915MHz in America instead of 865 MHz here in Europe.
.... Puhh I don't know. I will check it...
Fribur
commented
9 months ago The other thing you can try: ensure GPIO2 and 3 of the CMT2300A chip are set to "-1". I got the issue that the interrupts triggered by the CMT2300A chip in GPIO2 and 3 upon transmitting/receiving data are not reaching the ESP32 chip (on pin 16 and 19), so the ESP32 chip is waiting forever for data to arrive: "cmt": { "clk": 18, "cs": 4, "fcs": 5, "sdio": 23, "gpio2": -1, "gpio3": -1 },
When you set them to "-1"=not configured, then the ESP32 chips is constantly asking CMT2300A "is new data there?"
raebo
commented
9 months ago The other thing you can try: ensure GPIO2 and 3 of the CMT2300A chip are set to "-1". I got the issue that the interrupts triggered by the CMT2300A chip in GPIO2 and 3 upon transmitting/receiving data are not reaching the ESP32 chip (on pin 16 and 19), so the ESP32 chip is waiting forever for data to arrive: "cmt": { "clk": 18, "cs": 4, "fcs": 5, "sdio": 23, "gpio2": -1, "gpio3": -1 },
When you set them to "-1"=not configured, then the ESP32 chips is constantly asking CMT2300A "is new data there?"
Thank you, at least this works for the HMS-1600-4T
But unfortunately the HM-1500 is still offline :-(
Rustimation
commented
9 months ago Hi, if you're having a HMS-1600 and it connects the the openDTU, your openDTU is equipped with a CMT wireless module to send/receive data to/from your inverter. As it seems, you're also having a HM-1500 (not HMS-1500). In that case you're out of luck, as the HM inverters use a different wireless technology and the optenDTU needs to be equipped with a NRF wireless module. I'm not sure whether you can hack the openDTU so that it accepts both modules simultaneously. Rgds Chris
stefan123t
commented
9 months ago @Rustimation thanks for your hint, but he is using the OpenDTU Fusion board which has both an NRF24L01+ and an CMT2300A radio module on board. This is setup to work with both types of inverters 2.4GHz Bluetooth-like Enhanced Shockburst via NRF for 2nd Gen MI- (only in AhoyDTU at the moment as to my knowledge) and 3rd Gen HM- models and 868MHz Sub1G via CMT for both 3rd Gen communication protocol HMS- and HMT- models. Only the HMS-WiFi models need again a separate WLAN Access Point to talk to the DTUBI (built in DTU) using the NetworkCommands of the latest WiFi models.
@raebo did you compile the OpenDTU firmware yourself and which config (probably OpenDTU Fusion v2 with CMT2300A and NRF24) from the pin_mappings.json did you select for the OpenDTU Fusion board.
Also which version of OpenDTU Fusion is it v1 / v2 / v2.1 ? I guess it is v2.1 being the current production run from Tim & Andy.
Rustimation
commented
9 months ago @stefan123t: I stand corrected. Thanks for clearing that up. I wasn't aware of this variant. Rgds Chris
Fribur
commented
9 months ago Besides my own experience, this is the second example that the CMT2300A is not firing the interrupts it should fire on RX and TX. Who is familiar with configuring all the register of CMT2300A to look into what might be causing this? See in Discord where I posted a screenshot of a couple of registers I had monitored. I’m not quite sure how to debug on the side of CMT2300A if the interrupts are triggering or not.
stefan123t
commented
9 months ago @Fribur maybe @lumapu or @DanielR92 still remember something about the IRQ registers ?
raebo
commented
9 months ago Hi, if you're having a HMS-1600 and it connects the the openDTU, your openDTU is equipped with a CMT wireless module to send/receive data to/from your inverter. As it seems, you're also having a HM-1500 (not HMS-1500). In that case you're out of luck, as the HM inverters use a different wireless technology and the optenDTU needs to be equipped with a NRF wireless module. I'm not sure whether you can hack the openDTU so that it accepts both modules simultaneously. Rgds Chris
Thank you for the clarification, my experiences in hardware hacking are quiet low.....so this is not an option for me
So the conclusion for me is:
HMS-1600-4T is working with the PIN setting "gpio2": -1, "gpio3": -1
HM-1500 is not working cause of the missing NRF wireless module
@raebo did you compile the OpenDTU firmware yourself and which config (probably
OpenDTU Fusion v2 with CMT2300A and NRF24) from the pin_mappings.json did you select for the OpenDTU Fusion board. Also which version of OpenDTU Fusion is it v1 / v2 / v2.1 ? I guess it is v2.1 being the current production run from Tim & Andy.
No, I did not compiled anything by myself. I downloaded the official binary release.
@all thanks a lot for your support.
Best regards Boris
stefan123t
commented
9 months ago @raebo did you use the official OpenDTU build or a specific build for the OpenDTU Fusion board ?
And according to the docs from the Fusion board developers you should use the
opendtu-generic_esp32s3_usb.bin image here: https://github.com/tbnobody/OpenDTU/releases
After flashing you should select the right device profile from the pin_mapping.json for your board, i.e. OpenDTU Fusion v2 with CMT2300A and NRF24.
The OpenDTU Fusion board v2.1 does have both NRF and CMT hence it can communicate with both HM- and HMS-inverters a like. I am running the OpenDTU Fusion board with a custom build / fork from LennartF22 which supports the PoE hat available too. The Power-over-Ethernet add-on board is not (yet) supported with the stock firmware releases available at the original OpenDTU developed by tbnobody.
raebo
commented
9 months ago @raebo did you use the official OpenDTU build or a specific build for the OpenDTU Fusion board ?
And according to the docs from the Fusion board developers you should use the
opendtu-generic_esp32s3_usb.binimage here: https://github.com/tbnobody/OpenDTU/releasesAfter flashing you should select the right device profile from the pin_mapping.json for your board, i.e.
OpenDTU Fusion v2 with CMT2300A and NRF24.The OpenDTU Fusion board v2.1 does have both NRF and CMT hence it can communicate with both HM- and HMS-inverters a like. I am running the OpenDTU Fusion board with a custom build / fork from LennartF22 which supports the PoE hat available too. The Power-over-Ethernet add-on board is not (yet) supported with the stock firmware releases available at the original OpenDTU developed by tbnobody.
@stefan123t I've loaded already the correct release file.
This is what device info tells me:
Regarding the custom builds from LennartF22, in my opinion those build are referenced here https://github.com/tbnobody/OpenDTU/releases.
raebo
commented
9 months ago @stefan123t Do you have any further ideas how to fix my problem with the HM-1500??
Thanks Boris
stefan123t
commented
9 months ago @raebo thanks for pictures of some of your configuration. I doubt this is a hardware problem, as I have an OpenDTU Fusion board donated by Tim / Alliance Apps too, and it works flawless with my HM-600.
I would suggest you join our Discord channel as there are significantly more people able to help you troubleshoot your issue.
Also you mention that you have an HMS-1500 (CMT2300A) and later you talk about HM-1500 (NRF24L01+) ? These are two distinct models which use different wireless network chips to connect.
Though both chips are on the OpenDTU Fusion board, they should be distinguished when configuring the Inverter Serial IDs, etc. Posting at least the first seven digits of your Serial IDs would allow us to better detect which model you are actually owning ?
Also note that HMS-xxxxW models are again a different type which appeared on the market only this year (2023). They have a so called built-in DTU-BI which is not compatible with either of the above chips mounted on the OpenDTU Fusion board nor with OpenDTU software so far. Instead they can only be queried using NetworkCommands via a normal WLAN AP and some python library / plugin for HomeAssistant or e.g. on a Raspberry Pi.
stefan123t
commented
9 months ago Looking at your screenshots I have seen this is detected correctly:
116191027770 -> HM-1000/1200/1500-4T116484660502 -> HMS-1600/1800/2000-4THere are my (default) DTU settings, which work for me / my NRF24 based HM-600,
do not know for sure about the HMS model as I do not own one myself:
stefan123t
commented
9 months ago Regarding the System Info screenshots you posted earlier, please double check:
that your PIO Environment: opendtufusionv2
that your Radio Information is connected / configured or otherwise green
Please check your Info > Console tomorrow during daytime and attach a new / current Log from the console.
tbnobody
commented
6 months ago Any news on this issue? Still occouring or can it be closed?
gelsas
commented
4 months ago I have the same issue I have bought the AllianceApps OpenDTU Fusion
RX Period End
11:47:19.285 > All missing
11:47:19.285 > Nothing received, resend whole request
11:47:19.285 > TX RealTimeRunData 865.00 MHz --> 15 A0 09 4B EC 80 16 90 24 80 0B 00 66 38 A7 25 00 00 00 00 00 00 00 00 EB ED 68
11:47:19.788 > RX Period End
11:47:19.788 > All missing
11:47:19.788 > Nothing received, resend count exeeded
11:47:19.886 > TX AlarmData 865.00 MHz --> 15 A0 09 4B EC 80 16 90 24 80 11 00 66 38 A7 25 00 00 00 00 00 00 00 00 31 F6 B3
11:47:20.632 > RX Period End
11:47:20.632 > All missing
11:47:20.632 > Nothing received, resend whole request
11:47:20.632 > TX AlarmData 865.00 MHz --> 15 A0 09 4B EC 80 16 90 24 80 11 00 66 38 A7 25 00 00 00 00 00 00 00 00 31 F6 B3
11:47:21.431 > RX Period End
11:47:21.431 > All missing
11:47:21.431 > Nothing received, resend whole request
11:47:21.431 > TX AlarmData 865.00 MHz --> 15 A0 09 4B EC 80 16 90 24 80 11 00 66 38 A7 25 00 00 00 00 00 00 00 00 31 F6 B3
11:47:22.230 > RX Period End
11:47:22.230 > All missing
11:47:22.230 > Nothing received, resend whole request
11:47:22.230 > TX AlarmData 865.00 MHz --> 15 A0 09 4B EC 80 16 90 24 80 11 00 66 38 A7 25 00 00 00 00 00 00 00 00 31 F6 B3
11:47:23.022 > RX Period End
11:47:23.022 > All missing
11:47:23.022 > Nothing received, resend whole request
11:47:23.022 > TX AlarmData 865.00 MHz --> 15 A0 09 4B EC 80 16 90 24 80 11 00 66 38 A7 25 00 00 00 00 00 00 00 00 31 F6 B3
11:47:23.780 > RX Period End
11:47:23.780 > All missing
11:47:23.780 > Nothing received, resend count exeeded
11:47:23.780 > Fetch inverter: REDACTED
11:47:23.831 > TX RealTimeRunData 865.00 MHz --> 15 A0 09 4B EC 80 16 90 24 80 0B 00 66 38 A7 2C 00 00 00 00 00 00 00 00 BB 87 5B
11:47:24.369 > RX Period End
11:47:24.369 > All missing
11:47:24.369 > Nothing received, resend whole request
11:47:24.369 > TX RealTimeRunData 865.00 MHz --> 15 A0 09 4B EC 80 16 90 24 80 0B 00 66 38 A7 2C 00 00 00 00 00 00 00 00 BB 87 5B
11:47:24.912 > RX Period End
11:47:24.912 > All missing
11:47:24.912 > Nothing received, resend whole request
11:47:24.912 > TX RealTimeRunData 865.00 MHz --> 15 A0 09 4B EC 80 16 90 24 80 0B 00 66 38 A7 2C 00 00 00 00 00 00 00 00 BB 87 5B
11:47:25.120 > Admin AP remaining seconds: 10 / 180
11:47:25.461 > RX Period End
11:47:25.461 > All missing
11:47:25.461 > Nothing received, resend whole request
11:47:25.461 > TX RealTimeRunData 865.00 MHz --> 15 A0 09 4B EC 80 16 90 24 80 0B 00 66 38 A7 2C 00 00 00 00 00 00 00 00 BB 87 5B
11:47:26.001 > RX Period End
11:47:26.001 > All missing
11:47:26.001 > Nothing received, resend whole request
11:47:26.001 > TX RealTimeRunData 865.00 MHz --> 15 A0 09 4B EC 80 16 90 24 80 0B 00 66 38 A7 2C 00 00 00 00 00 00 00 00 BB 87 5B Previously I had an Hoymiles DTU connected but I unplugged that one.
For some reason it does not connect. The distance to the inverter is about 2M. So that shouldn't be the issue. What could cause this? What could I try to do?
rh0-me
commented
2 months ago Instead of opening a new issue i will just comment here, because my issue is kinda similar to this one. I bought a DTU from blinkparts.com, soldered the parts and connected it with Wi-Fi and a HMS-2000-4T inverter. The distance to the inverter is roughly 2m. The dtu was working fine with the stock firmware from blinkyparts. One day though it started not to get any data from the inverter (a few days after the MQTT setup). I tried:
Today I have the same problem. Upgraded to the most recent firmware (24.6.29) and set up the poll interval to 15s and the transmitting power to +20 dBm.
These are the current console logs:
RX Period End
21:07:16.428 > All missing
21:07:16.428 > Nothing received, resend count exeeded
21:07:16.474 > TX AlarmData 865.00 MHz --> 15 94 81 33 56 80 16 27 52 80 11 00 66 8A E7 61 00 00 00 00 00 00 00 00 9C AA 4B
21:07:17.284 > RX Period End
21:07:17.284 > All missing
21:07:17.284 > Nothing received, resend whole request
21:07:17.284 > TX AlarmData 865.00 MHz --> 15 94 81 33 56 80 16 27 52 80 11 00 66 8A E7 61 00 00 00 00 00 00 00 00 9C AA 4B
21:07:18.084 > RX Period End
21:07:18.084 > All missing
21:07:18.084 > Nothing received, resend whole request
21:07:18.084 > TX AlarmData 865.00 MHz --> 15 94 81 33 56 80 16 27 52 80 11 00 66 8A E7 61 00 00 00 00 00 00 00 00 9C AA 4B
21:07:18.908 > RX Period End
21:07:18.908 > All missing
21:07:18.908 > Nothing received, resend whole request
21:07:18.908 > TX AlarmData 865.00 MHz --> 15 94 81 33 56 80 16 27 52 80 11 00 66 8A E7 61 00 00 00 00 00 00 00 00 9C AA 4B
21:07:19.719 > RX Period End
21:07:19.719 > All missing
21:07:19.719 > Nothing received, resend whole request
21:07:19.719 > TX AlarmData 865.00 MHz --> 15 94 81 33 56 80 16 27 52 80 11 00 66 8A E7 61 00 00 00 00 00 00 00 00 9C AA 4B
21:07:20.468 > RX Period End
21:07:20.468 > All missing
21:07:20.468 > Nothing received, resend count exeeded
21:07:20.521 > TX SystemConfigPara 865.00 MHz --> 15 94 81 33 56 80 16 27 52 80 05 00 66 8A E7 61 00 00 00 00 00 00 00 00 88 BE 5F
21:07:20.782 > RX Period End
21:07:20.782 > All missing
21:07:20.782 > Nothing received, resend whole request
21:07:20.782 > TX SystemConfigPara 865.00 MHz --> 15 94 81 33 56 80 16 27 52 80 05 00 66 8A E7 61 00 00 00 00 00 00 00 00 88 BE 5F
21:07:21.036 > RX Period End
21:07:21.036 > All missing
21:07:21.036 > Nothing received, resend whole request
21:07:21.036 > TX SystemConfigPara 865.00 MHz --> 15 94 81 33 56 80 16 27 52 80 05 00 66 8A E7 61 00 00 00 00 00 00 00 00 88 BE 5F
21:07:21.291 > RX Period End
21:07:21.291 > All missing
21:07:21.291 > Nothing received, resend whole request
21:07:21.291 > TX SystemConfigPara 865.00 MHz --> 15 94 81 33 56 80 16 27 52 80 05 00 66 8A E7 61 00 00 00 00 00 00 00 00 88 BE 5F
21:07:21.547 > RX Period End
21:07:21.547 > All missing
21:07:21.547 > Nothing received, resend whole request
21:07:21.547 > TX SystemConfigPara 865.00 MHz --> 15 94 81 33 56 80 16 27 52 80 05 00 66 8A E7 61 00 00 00 00 00 00 00 00 88 BE 5F
21:07:21.752 > RX Period End
21:07:21.752 > All missing
21:07:21.752 > Nothing received, resend count exeeded
21:07:28.409 > Fetch inverter: 116494813356
21:07:28.409 > Request SystemConfigPara
21:07:28.448 > TX ChannelChangeCommand 868.00 MHz --> 56 94 81 33 56 80 16 27 52 02 15 21 14 14 F3
21:07:28.492 > RX Period End
21:07:28.492 > All missing
21:07:28.492 > Nothing received, resend whole request
21:07:28.492 > TX ChannelChangeCommand 868.00 MHz --> 56 94 81 33 56 80 16 27 52 02 15 21 14 14 F3
21:07:28.543 > RX Period End
21:07:28.543 > All missing
21:07:28.543 > Nothing received, resend whole request
21:07:28.543 > TX ChannelChangeCommand 868.00 MHz --> 56 94 81 33 56 80 16 27 52 02 15 21 14 14 F3
21:07:28.589 > RX Period End
21:07:28.589 > All missing
21:07:28.589 > Nothing received, resend whole request
21:07:28.589 > TX ChannelChangeCommand 868.00 MHz --> 56 94 81 33 56 80 16 27 52 02 15 21 14 14 F3
21:07:28.633 > RX Period End
21:07:28.633 > All missing
21:07:28.633 > Nothing received, resend whole request
21:07:28.633 > TX ChannelChangeCommand 868.00 MHz --> 56 94 81 33 56 80 16 27 52 02 15 21 14 14 F3
21:07:28.651 > RX Period End
21:07:28.651 > All missing
21:07:28.651 > Nothing received, resend count exeeded
21:07:28.693 > TX RealTimeRunData 865.00 MHz --> 15 94 81 33 56 80 16 27 52 80 0B 00 66 8A E7 70 00 00 00 00 00 00 00 00 16 71 11
21:07:29.254 > RX Period End
21:07:29.254 > All missing
21:07:29.254 > Nothing received, resend whole request
21:07:29.254 > TX RealTimeRunData 865.00 MHz --> 15 94 81 33 56 80 16 27 52 80 0B 00 66 8A E7 70 00 00 00 00 00 00 00 00 16 71 11
21:07:29.812 > RX Period End
21:07:29.812 > All missing
21:07:29.812 > Nothing received, resend whole request
21:07:29.812 > TX RealTimeRunData 865.00 MHz --> 15 94 81 33 56 80 16 27 52 80 0B 00 66 8A E7 70 00 00 00 00 00 00 00 00 16 71 11
21:07:30.368 > RX Period End
21:07:30.368 > All missing
21:07:30.368 > Nothing received, resend whole request
21:07:30.368 > TX RealTimeRunData 865.00 MHz --> 15 94 81 33 56 80 16 27 52 80 0B 00 66 8A E7 70 00 00 00 00 00 00 00 00 16 71 11
21:07:30.926 > RX Period End
21:07:30.926 > All missing
21:07:30.926 > Nothing received, resend whole request
21:07:30.926 > TX RealTimeRunData 865.00 MHz --> 15 94 81 33 56 80 16 27 52 80 0B 00 66 8A E7 70 00 00 00 00 00 00 00 00 16 71 11
21:07:31.435 > RX Period End
21:07:31.435 > All missing
21:07:31.435 > Nothing received, resend count exeeded
21:07:31.482 > TX AlarmData 865.00 MHz --> 15 94 81 33 56 80 16 27 52 80 11 00 66 8A E7 70 00 00 00 00 00 00 00 00 CC 6A CA
21:07:32.294 > RX Period End
21:07:32.294 > All missing
21:07:32.294 > Nothing received, resend whole request
21:07:32.294 > TX AlarmData 865.00 MHz --> 15 94 81 33 56 80 16 27 52 80 11 00 66 8A E7 70 00 00 00 00 00 00 00 00 CC 6A CA
21:07:33.097 > RX Period End
21:07:33.097 > All missing
21:07:33.097 > Nothing received, resend whole request
21:07:33.097 > TX AlarmData 865.00 MHz --> 15 94 81 33 56 80 16 27 52 80 11 00 66 8A E7 70 00 00 00 00 00 00 00 00 CC 6A CA
21:07:33.915 > RX Period End
21:07:33.915 > All missing
21:07:33.915 > Nothing received, resend whole request
21:07:33.915 > TX AlarmData 865.00 MHz --> 15 94 81 33 56 80 16 27 52 80 11 00 66 8A E7 70 00 00 00 00 00 00 00 00 CC 6A CA
21:07:34.721 > RX Period End
21:07:34.721 > All missing
21:07:34.721 > Nothing received, resend whole request
21:07:34.721 > TX AlarmData 865.00 MHz --> 15 94 81 33 56 80 16 27 52 80 11 00 66 8A E7 70 00 00 00 00 00 00 00 00 CC 6A CA
21:07:35.477 > RX Period End
21:07:35.477 > All missing
21:07:35.477 > Nothing received, resend count exeeded
21:07:35.526 > TX SystemConfigPara 865.00 MHz --> 15 94 81 33 56 80 16 27 52 80 05 00 66 8A E7 70 00 00 00 00 00 00 00 00 D8 7E DE
21:07:35.787 > RX Period End
21:07:35.787 > All missing
21:07:35.787 > Nothing received, resend whole request
21:07:35.787 > TX SystemConfigPara 865.00 MHz --> 15 94 81 33 56 80 16 27 52 80 05 00 66 8A E7 70 00 00 00 00 00 00 00 00 D8 7E DE
21:07:36.042 > RX Period End
21:07:36.042 > All missing
21:07:36.042 > Nothing received, resend whole request
21:07:36.042 > TX SystemConfigPara 865.00 MHz --> 15 94 81 33 56 80 16 27 52 80 05 00 66 8A E7 70 00 00 00 00 00 00 00 00 D8 7E DE
21:07:36.297 > RX Period End
21:07:36.297 > All missing
21:07:36.297 > Nothing received, resend whole request
21:07:36.297 > TX SystemConfigPara 865.00 MHz --> 15 94 81 33 56 80 16 27 52 80 05 00 66 8A E7 70 00 00 00 00 00 00 00 00 D8 7E DE
21:07:36.554 > RX Period End
21:07:36.554 > All missing
21:07:36.554 > Nothing received, resend whole request
21:07:36.554 > TX SystemConfigPara 865.00 MHz --> 15 94 81 33 56 80 16 27 52 80 05 00 66 8A E7 70 00 00 00 00 00 00 00 00 D8 7E DE
21:07:36.759 > RX Period End
21:07:36.759 > All missing
21:07:36.759 > Nothing received, resend count exeeded
What happened?
I've bought an AllianceApps OpenDTU Fusion from this page https://www.ebay.de/itm/126153383188?var=427155260485
The DTU is connected with the wlan and has the newest firmware.
Afte restarting the DTU both invertrs are online but after a couple of minutes I receive the following message:
The log gives me the following data
Here is picture of the inverter infos:
Thank you for your help and assistance
Greetings Boris
To Reproduce Bug
OPEN DTU ist connected to the WLAN
I have two inverters:
The PIN Mapping file is attached pin_mapping(1).json
Expected Behavior
The infoscreen for the inversters should be green.
But is unfortunately red
Event Log shows
Install Method
Pre-Compiled binary from GitHub
What git-hash/version of OpenDTU?
v23.11.16
Relevant log/trace output
Anything else?
No response