Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

web page publish and main loop share the MQTT send queue

未关闭
  • 哪里不对？
#616 2 条评论 0 个 reaction 已指派 1 人 在 GitHub 查看

@Yukti007 已经在做这个了。

开始于 2026年10月13日。

评估

这个 Issue 还没有评估数据。

描述

High Priority

Describe the bug
Messages going to the MQTT broker first go into a small queue of 8 slots. The main program adds messages to it (alarm Acknowledge/Dismiss/Shelve replies and the "online" message). The Broker Console web page also adds messages when someone presses Publish. The web page runs in a separate task that can interrupt the main program at any moment, and there is no lock. Both can pick the same empty slot. Then one message is lost, or a message goes out with one sender's topic and the other sender's text.

Short Summary of the expected behavior:
Every message added to the MQTT queue is sent once, on the right topic, with the right text, no matter which part of the program added it.

Short Summary of the buggy behavior:
If the web page and the main program add a message at the same moment, one message can be lost, or the topic and the text can come from different messages. The web page can still say "published".

To Reproduce
Found by reading the code. Not yet tested on a real Krake board. The two writes must overlap within microseconds, so this is hard to make happen on purpose. Suggested steps to try:

  1. Connect the Krake to Wi-Fi and an MQTT broker. Subscribe to its ACK topic and to a Broker Console publish topic with an MQTT client.
  2. Open the Broker Console web page on the Krake.
  3. Use a script to send many POST requests to /broker-console/publish very quickly.
  4. At the same time, send alarms to the Krake and acknowledge them on the knob, or just let the "online" message go out every 10 seconds.
  5. See error: some messages are missing on the broker, or an ACK-topic message arrives on the Broker Console topic (or the other way round).

Expected behavior
All messages arrive at the broker, each on its own topic with its own text. An operator's Acknowledge is never lost.

Screenshots
None. Not yet tested on hardware.

Hardware description
Model: Krake (GPAD_API firmware), checked against main at commit b6ea4b3 (2026-09-20)
Serial Number: N/A (found by reading the code)
Other: Affects any Krake with Wi-Fi/MQTT and the web page in use.

Test Equipment
Model: N/A (not yet tested)
Serial Number: N/A

Additional context
Where in the code:

Why it happens: queueMqtt() finds an empty slot, copies in the topic, then the text, and only then marks the slot as used. The web task can interrupt in the middle of that, see the same slot as empty, and write into it too. There is no mutex, critical section or FreeRTOS queue: a search of the firmware for mutex, Semaphore, portENTER_CRITICAL and xQueue finds nothing.

How likely: low. The two writes must overlap within microseconds. But it happens at random, cannot be reproduced on demand, and a lost Acknowledge matters on an alarm device.

Possible fix: protect queueMqtt() and serviceMqttQueue() (and the matching SPI mirror functions) with a FreeRTOS mutex or a short critical section. Or have the web handler pass the message to the main loop through a FreeRTOS queue, so only loop() touches the MQTT queue. The same handler also changes saved publish topics and settings from the web task (lines 2204–2221), so the fix should cover those too.

Not checked: the async web server library is not listed in platformio.ini, so its exact task priority and core setting could not be confirmed from this repo.

Related: #370 (MQTT messages published), #283 (shared global variables).

主要语言
C++
星标
9
派生
6
30 天内没有已合并 PR

环境准备

这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

PubInv/krake 的其他 Issue

查看 PubInv/krake 的全部 Issue

相似的 Issue

更多 C++ Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。