Despite all our efforts, sometimes our software or our programming libraries do not behave in the way expected by our customers. This can be due to a bug or to a too complex interface. If this happens to you, support is available to help you solve these issues. However, we often get vague or incomplete questions. In order to avoid unnecessary email exchanges, here is a list of recommendations for contacting support.
First of all, a few words on Yoctopuce support. Yoctopuce doesn't have a support team distinct from the development team. The support team is the development team.
The advantage for you is that you directly communicate with the people able to solve your issues. No need to spend two frustrating days navigating between the different support lines.
The advantage for us is that it allows us to keep a direct contact with our customers and to very quickly fix a faulty feature. It is not uncommon for a fix to be released a few hours after the bug report came in.
However, in order to answer as efficiently as possible, we need a maximum of information on your problem. A simple email with the message "The VirtualHub doesn't see my Yocto-Light-V2" won't allow us to help you efficiently.
Here are some pieces of advice to help us identify your problem and solve it as fast as possible.
Describe the context
The first recommendation is to describe the context of your problem. Unfortunately, we often receive emails without any description of what the user is trying to do. Take the time to briefly describe you application and what you are trying to do. The more information we have, the better for us to help you efficiently.
If the application displays an error message, send it to us in its entirety in your email. These error messages allow us to rather precisely identify the source of the error, as long as we see the complete version.
If there is no error windows, but the application doesn't work, launch the executable again from a terminal. Some errors happen at the very beginning and we can't display a window with the error message. For example, under Linux, if Mono is not installed, Yocto-Visualization doesn't start and we don't display any window. But if you run it from a terminal, the error message is displayed on the standard output.
In the same way, if you can't access the web interface of the VirtualHub, run it again from a terminal and see if an error message is displayed.
Send the logs
When you have a problem with the VirtualHub or a Yoctopuce application, send us the execution logs. The logs are a big help to understand the issue, in particular if the problem is sporadic.
The VirtualHub logs are available from the web interface. The logs of the Yoctopuce applications, such as the Yocto-Visualization, are available from the contextual menu.
The "Show debug information" button
The YoctoHubs and the VirtualHub have a "Show debug information" button at the bottom of their web interface. This button opens a window containing all the information that you need to pass on to support.
Practically, here is the information which is displayed on this page:
- The list of all the modules that were detected.
- The value of all the parameters of all the modules (without the passwords).
- The logs of all the modules.
- The list of all the files that were uploaded on the modules, but not their content.
- The content of the potential core dump of the YoctoHubs.
The Show debug information button
The "save" button of this window enables you to save the content of this window in the HTML format so that you can easily send it to us by email.
Describe your architecture
We have more than 50 distinct modules, 15 programming libraries, 6 applications, and we support 3 OS. Some customers have very simple systems, others have systems with tens of modules spread over several buildings. So we can't guess which combination you are using.
Remember to list the different parts of your architecture. Usually, the information that we need can be split into four categories:
- The Yoctopuce modules
- The OS with which you work
- The Yoctopuce application
- The programming library
The Yoctopuce modules
List all the Yoctopuce modules that are used in your system, as well as their firmware version.
I use a Yocto-Meteo-V2 (firmware 37128), a Yocto-Light-V3 (firmware 37128), and a YoctoHub-Wireless-n (firmware 42261).
Don't forget to say how the modules are connected.
The Yocto-Mereo-V2 is connected by USB on my machine and the Yocto-Light-V3 is connected on a YoctoHub-Wireless-n.
If one of the modules is connected on a USB port, let us know whether you use a USB hub and whether it is powered. A large number of issues are simply due to a non-powered USB hub.
The Yocto-Meteo-V2 is connected directly on a USB port of my laptop, and the Yocto-Light-V3 is connected to a non-powered USB hub.
The OS and the machine used
We support 3 OSes (Windows, Linux, and macOS) and for each OS several architectures. Having the precise OS and architecture information helps use understand and isolate the issue. If need be, this information helps us to reproduce the situation in our premises.
If you use Windows, tell us which version (Windows 7, Windows 10 Pro, ...) and whether it's a 32 or 64 bit version. For Linux, on top of the distribution, let us know the CPU type that you use. If you don't know, use the "uname -a" and "lsb_release -a" commands and send us the results.
My machine is a Raspberry Pi 4, on which is installed Raspberry Pi OS and here are the results of the uname and lsb_release commands: ...
The VirtualHub or the Yoctopuce applications
If you use the VirtualHub or an application such as Yocto-Visualization, let us know which version you use, and how you installed it. For example, for the VirtualHub, you can use an installer, MSI for Windows or APT for Linux, or you can have download a zip archive with the executable. If you used the zip archive, specify which executable you are launching.
I run the VirtualHub which is located in the /armhf subdirectory of the zip archive.
The programming libraries
If your error comes from one of our programming libraries, the simplest and the most efficient for us is to get the source code from which the problem arises. If it's not possible because of size or of data protection issues, include only the part of your code which uses our library.
On top of the code, specify which compiler or interpreter you use. Don't forget to mention the version and potentially the variant (32 or 64 bits) of your application.
The following code doesn't work with Python 2.7 32bits under Windows.
Now that your have all the information, you only need to contact support at the firstname.lastname@example.org email address. We are very reactive and most of the time you should have an answer in less than 24 hours.