Hi everyone,
I’ve been working on a few ESP32-based automation projects recently (mostly using ESPHome + Home Assistant), and I’m now reaching a point where things are getting more complex, multiple devices, integrations, and frequent updates.
While the hardware side (like KC868 boards) is quite flexible, managing firmware updates, monitoring, and deployment across multiple nodes is becoming a challenge.
That got me thinking about bringing DevOps concepts into IoT development, things like:

• CI/CD pipelines for firmware updates
  
• Version control for configurations (ESPHome / Arduino)
  
• Automated testing before deploying to live devices
  
• Monitoring uptime and performance across nodes
  

• Are you using any DevOps-style workflows for your ESP32 or KinCony projects?
  
• How do you manage updates across multiple devices?
  
• Any tools or best practices for maintaining stability at scale?
  
• Has anyone tried integrating GitOps or containerized services with their IoT backend?
  

this command work ok:
01 05 00 00 ff 00 8c 3a

but read coil report 07 coils enabled (shifted)

coil write from 08 coil and above does nothing: no LEDs, no affection on coils read

- Firmware Version: v3.24.3 (Build Date: Apr 12 2026)
- Hardware: A16v3
- Communication: Modbus RTU (RS485)

## Description:

I have encountered an issue regarding the implementation of Modbus Function Code 05 (Write Single Coil).

According to the official Modbus specification, to turn a coil ON, the data field must send FF00. To turn it OFF, the data field must send 0000. However, my A16v3 running firmware v3.24.3 does not seem to accept this standard.

## Observed Behavior:

The device expects (or only responds to) a "bit-encoded" state in the data field. For example:

Instead of FF 00, the device expects 01 00 (or similar bit masks) to activate the coil.

Instead of 00 00, it expects 00 00.

This behavior is non-standard. It appears the firmware is treating FC05 as if it were a "Mask" or mimicking the data structure of FC15 (Write Multiple Coils) rather than the strict FF00/0000 pattern required by the Modbus standard.

## Steps to Reproduce:

Establish Modbus TCP connection to the device (IP: 10.130.1.43).

Send standard Modbus FC05 frame to any valid coil address (e.g., 00 01):

Standard ON: [Slave ID] 05 [Addr High] [Addr Low] FF 00 [CRC]

Standard OFF: [Slave ID] 05 [Addr High] [Addr Low] 00 00 [CRC]

Observe that the coil state does not change (or the device returns an exception/incorrect response).

Send a modified frame using bit-encoded data (e.g., 01 00 for ON).

Observe that the coil toggles successfully.

## Expected Behavior:

The device should strictly adhere to the Modbus specification for Function Code 05, using FF00 for ON and 0000 for OFF.

## Questions / Requests:

- Is this a known issue in v3.24.3?

-Is there a configuration flag in the Web UI (e.g., "Strict Mode," "Legacy Mode," or "Compatibility Mode") that can switch the device to standard Modbus compliance?

-If not, is this planned to be fixed in a future firmware update?

## Additional Context:

Software Version: v3.24.3

Build Date: Apr 12 2026

I am using a standard Modbus master software (PLC/SCADA) that strictly adheres to the FF00 standard, so I cannot easily modify the protocol structure on the master side.

Hello.

I want to upgrade my N30 (KCS v3.15.0) with KCS v3.24.3
Do I need to make new ARM CPU update firmware (support 0.001kwh now https://www.kincony.com/forum/showthread.php?tid=9107) before or not? Or KCS update is enougth?

Best Regards.