Tuhi GUI vs Tuhi server
Tuhi has (currently) two distinct components: a DBus session daemon that performs the actual communication with the device and a GUI component that talks to that daemon. These are two separate processes started by the tuhi executable.
For development, both components can be started separately via ./tuhi-server.py and ./builddir/tuhi-gui.devel. Note that the server component is started from the source directory, it doesn't need to get built.
In the source tree, the server is in tuhi/ and the GUI is in tuhigui/.
Do not try to start ./builddir/tuhi, ./builddir/tuhi-gui or ./builddir/tuhi-server, they will use the system-installed packages and won't work as expected. Always use the .devel executables.
Resetting devices
Tuhi stores the device data in $HOME/.local/share/tuhi/<btaddress> (i.e. $XDG_DATA_HOME) The primary file is settings.ini which is how Tuhi remembers devices it has already seen. Removing that device and/or the whole folder makes the device unknown again and the device has to be re-registered.
BlueZ ManufacturerData
There's an oddity about the ManufacturerData property on the devices. That property is a 7-byte value when the device is running normally but a 4-byte value when the device is in register mode. The update of that property is delayed though, so a device may be in register mode before the ManufacturerData reverts to 4 bytes. And, crucially, it may stay in 4-byte mode for a successful registration but switches to 7 bytes on the next connection. When a registration times out, the device may stay in 4-byte or 7-byte ManufacturerData, it depends on some previous state.