ms
8f3756b1fe
wysylanie U_A, U_B, U_C do MQTT w formacie JSON podobnie jak dla innych pomiarów (np. Hz) wysylanie U_A, U_B, U_C do InfluxDB w batchu razem z innymi pomiarami (nie osobno)
69 lines
3.6 KiB
Markdown
69 lines
3.6 KiB
Markdown
|
||
❯ frequency of reports of orno measuring is very rare , value not changes. try to analyse this problem
|
||
|
||
● I'll analyze the code to understand the ORNO measuring report frequency issue. Let me first read the relevant file.
|
||
|
||
● Read 1 file (ctrl+o to expand)
|
||
|
||
● I analyzed the code and found two critical bugs that explain the rare reports and stuck values:
|
||
|
||
Problem 1: Spike Detection Logic Bug (Causes "Values Not Changing")
|
||
|
||
Lines 618-624, 632-638, 644-650, 656-662, and 668-674 have a logic error. When a spike is detected, the code sends previous
|
||
values but never updates the stored previous value. This means once a spike is detected, the system reports old values forever.
|
||
|
||
Example from voltage check:
|
||
if(spike_U) {
|
||
send_voltage = prev_voltage; // Send old value
|
||
printf("ORNO: Voltage spike detected. Sending previous values.\n");
|
||
// BUG: prev_voltage is NOT updated here!
|
||
} else {
|
||
send_voltage = current_voltage;
|
||
prev_voltage = current_voltage; // Only updated when NO spike
|
||
}
|
||
|
||
Impact: If your voltage/current/power changes by more than 80% (or frequency by 5%), the system will get stuck reporting the
|
||
old values indefinitely.
|
||
|
||
Problem 2: SUN2K Retry Loop (Causes "Rare Reports")
|
||
|
||
Lines 796-799 show SUN2K has a retry loop with up to 10 attempts per register:
|
||
do {
|
||
num = modbus_read_timed(ctx, mbReg[i].ireg, mbReg[i].num_reg, reg);
|
||
} while ((num != mbReg[i].num_reg) && (proba++ < 10));
|
||
|
||
With a 0.9s timeout (line 766) and ~19 registers to read, if SUN2K is unresponsive this can delay each loop iteration by up to
|
||
~3 minutes (19 registers × 10 retries × 0.9s = 171s).
|
||
|
||
Since ORNO is read before SUN2K in the same loop, ORNO reports become rare when SUN2K has communication issues.
|
||
|
||
Recommendations
|
||
|
||
1. Fix spike detection - Update prev_* values even when spikes are detected, or the values will never update after any
|
||
significant change:
|
||
// Current buggy code:
|
||
if(spike_U) {
|
||
send_voltage = prev_voltage;
|
||
} else {
|
||
send_voltage = current_voltage;
|
||
prev_voltage = current_voltage; // Missing in spike branch!
|
||
}
|
||
|
||
// Fixed version:
|
||
if(spike_U) {
|
||
printf("ORNO: Voltage spike detected. Using previous values.\n");
|
||
}
|
||
send_voltage = current_voltage; // Always use current
|
||
prev_voltage = current_voltage; // Always update prev
|
||
2. Reduce SUN2K impact - Either:
|
||
- Reduce proba limit from 10 to 2-3 attempts
|
||
- Reduce response timeout from 900ms to 300ms
|
||
- Run SUN2K in a separate thread or process
|
||
- Disable SUN2K if not needed (#define READ_SUN2K false)
|
||
3. Add debugging - The code already has good logging. Check if you see "spike detected" messages or SUN2K timeout errors in
|
||
your logs.
|
||
|
||
The combination of these bugs explains why values appear stuck (spike detection) and reports are infrequent (SUN2K delays).
|
||
|
||
✻ Sautéed for 3m 13s
|