Repository navigation
Conversation
…ation. Prevent sending rejected commands and add documentation. Hardware verified on Aquarea L.
Add 26 readback topics (TOP144-TOP169) for documented fields in the normal heat pump data block, including SG Ready capacity settings, concrete drying, heater configuration, actual operating states, zone activity and room/DHW operation time limits. Add five commands for automatic heat/cool switching temperatures, room and DHW operation time limits, and quiet schedule activation. Validate complete integer payloads before constructing a telegram; reject malformed, out-of-range and invalid-step inputs without sending a command. Preserve existing topic IDs and reuse the shared decoder and command tables so the additions are also available through HTTP and rules. Document byte mappings, payload encodings, readback topics and the distinction between protocol ranges and model-specific menu limits. Leave uncertain protocol fields and zone sensor configuration unchanged. Validation: - 78 setter/dispatch cases passed - 26 decoder/MQTT cases passed - 24 rules regression scenarios passed - ESP8266 build passed with core 3.1.2 - ESP32-S3 build passed with core 3.3.11 New writes follow documented telegram examples; hardware acceptance and model-specific menu limits remain to be verified.
Works perfect on my Auqarea LT 5kW
|
|
What about relay status ? |
You mean the relay on the board? This PR is only about Aquarea Get and Set Parameters. |
|
Yes, the two relays on the large heishamon board. |
|
@sigma415 just use retaining flag on mqtt topic and use it as indication. |
|
Thanks, I know the retain flag. |
Same are on hardware.. First heishamon don't store it's status, so retain flag will triger last state after heishamon crash/reboot/offline. |
Publish both onboard relay states under gpio/relay/{one,two}/state
using retained 0/1 payloads.
Report states after MQTT relay commands, on MQTT reconnect, and at
the configured full-data resend interval. Detect changes made by
rules at the end of each main loop and retry failed publications.
Document the status topics and clarify that they report GPIO output
levels rather than mechanical relay contact feedback.
Put it knows the level of the gpio that triggering the relay. And this complies to the state of the relay. That ist the way I implemented it. |
Add TOP170 and TOP171 to the main page for Relay 1 and Relay 2. Read their states directly from GPIO21 and GPIO47 and display On/Off alongside the configured MQTT state topics. Refresh relay states every five seconds independently of MQTT connectivity and document the new topic IDs and JSON output.
So it shows the state in the UI, updated every 5 seconds and sends a MQTT message, when it changes or when the interval (e.g., 300 sec) arrives.
|
Heishmon writes to ESP GPIO, but can not read it ? |
@kretzp: Thank you. That's exactly what we need. Would this be implemented in future Heishamon firmware ? |
Thank you! Finally the old issue #889 is being fixed. MQTT retain would not work with systems that use rules for local processing and MQTT for remote monitoring. Will that also make the REST Api for relay control function? It has been part of the translated readme files, for example: And another point, entirely different but since you are currently working on MQTT: |
|
@kretzp : I own a actual K-series, R32 split 7kW. If you could provide me your preliminary large-board.bin and md5, I could and would test your code also with K-series. |
This pull request has a build. You can download it here: |
I will check it |
HeishaMon receives several documented heat pump settings and operating states without exposing them as individual MQTT topics. The protocol documentation also contains write examples for settings that currently have no named command.
This change adds 26 readback topics and five setting commands through the existing decoder and command tables. Existing topic names and IDs remain unchanged.
The new readback topics, TOP144–TOP169, cover:
Five new commands are available under
<base_topic>/commands/:SetHeatToCoolTempSetCoolToHeatTempSetRoomOperationMaxTimeSetDHWHeatupMaxTimeSetQuietModeSchedule0x40off /0x80onFor example, publishing
90to<base_topic>/commands/SetRoomOperationMaxTimesends a command with byte 97 set to0x04. Publishing91is rejected without sending a telegram because the setting uses 30-minute increments.The commands validate the complete integer payload before modifying the command buffer. Empty, malformed, out-of-range and invalid-step inputs are rejected without transmission. Each accepted command sets only its intended field in the standard command template.
The shared tables also expose these additions through the existing HTTP and rules interfaces.
SetQuietModeScheduletoggles the existing schedule; it does not configure schedule times or change the quiet level.MQTT-Topics.mdandProtocolByteDecrypt.mddocument the topic names, payloads, byte mappings and readback relationships. Validation ranges represent nonzero protocol encodings; individual heat pump models may enforce narrower installer-menu limits.Uncertain fields—including external heater timing, the possible bypass valve, the heat pump power field and the possible T-CAP indicator—remain unchanged. Zone sensor configuration and the conflicting second room thermostat byte mapping are also outside this change.
Validation completed successfully:
The new write commands follow the repository’s documented telegram examples. Hardware acceptance and model-specific menu limits have not yet been verified.