dodane logowanie wysyłanych danych do InfluxDB (przez --log)

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)

kimi_analyse2.md

@@ -0,0 +1,68 @@
+
+❯ 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