- Create a new topic for your issue. Don't hijack an existing topic if there is any doubt whether you have the exact same problem. Use keywords for your specific problem in the topic title. Don't just say something generic like "OTGW problem".
- Indicate the equipment you are using. This includes at least the hardware version of the OTGW (printed on the circuit board) and the version of the firmware running on the PIC (can be obtained with the PR=A command). When using a WiFi add-on module, indicate which firmware you installed on the ESP8266, including its version. Information about the boiler and thermostat may also be useful.
- Try to reduce the number of components involved. If your problem description includes some special firmware on the WiFi module that talks to some obscure home automation software, you can only expect to get assistance from people who happen to know all of the components. If you cannot observe the problem using only the OTGW and OTmonitor, consider if this forum is the right place to raise your problem.
- Provide a clear description of what you are trying to achieve, what happens, and what you expected to happen. Mention your original goal, not just a problem you encounter somewhere down the road while trying to reach that goal. For example: You want to get the return water temperature from your boiler. It does not show up in the logs. So you decide to add a temperature sensor to the OTGW, attached to the return pipe near the boiler. You configured the GPIO ports and still you don't get a return water temperature. Don't ask: "How to get readings from an external temperature sensor?" Ask: "How to get the return water temperature?". It is possible that your boiler is capable of providing that information, if something would just request it. The solution may then be as simple as issuing an AA=28 command to the OTGW and the whole external sensor idea was a false lead.
- Unless it makes absolutely no sense, provide a message log that covers an occurrence of the problem. The log should show the messages and other responses from the OTGW along with a time stamp. A log where the messages have been suppressed by the PS=1 command is not useful. The easiest way to create a log is by using the OTmonitor tool (Menu: Options → Logging). Preferably switch off the "Include details of bit fields" option. It provides no additional information and only makes the log bigger than it needs to be. If the log file is large, you can zip or gzip it and attach it to your post. The forum does not allow plain text files as attachments. Smaller logs can be included in the post in a code block (using the </> button).
- Provide details of the things you have already done to investigate the issue. Not helpful are remarks like: "I tried everything" or: "The only way to solve the problem is to power-cycle the OTGW". When you ask for help, you apparently hope that there is some other way to fix the problem than what you have already attempted. Then specify what you have tried, to avoid people suggesting things you have already ruled out.
- Also provide details, including a fresh log, when trying a possible solution that has been suggested. Don't just respond back that it "didn't work". It may not have been a complete solution, but something may have changed nonetheless. These differences could provide additional clues.
- Subscribe to your topic so you will be notified of any responses and follow up questions.
Creating an effective incident report
Moderator: hvxl
Creating an effective incident report
In the years of providing support for the OTGW on this forum, I found that some people post a very terse problem description that contains almost no clues to understand what is going on for someone trying to help. It then takes several rounds of questions and answers to even get the problem clear. This takes much effort and delays the resolution of the problem. So, based on some of my experiences, I have created a list of things you may want to consider when reporting a problem:
Schelte