Switch back-end from Python to C++ #17
Conversation
The hid_wiimote module seems to interfere with communication between Python and the balance board (as I think it connects first). Instead of fighting against it, rewrite the backend in C++ and use xwiimote to talk to the hid_wiimote module.
Make the balance board disconnect when pressing the disconnect button by using libudev to get the board's address & then connect to BlueZ with DBus (via the giomm library) to perform the disconnection.
When the XWiiIface Dispatch method returns an event of XWII_EVENT_WATCH, this means that the board has disconnected (as we haven't enabled hotplug events). Use this information to send the DISCONNECTED status to the UI if the board disconnects for any reason, not just when we have told it to. Also tidy up the connect / disconnect code to be driven by received messages instead of using a flag in the board event loop.
As we can now find any paired & connected Balance Board dynamically, the config parameter for setting the board's MAC address so that we know what to connect to is no-longer necessary.
The xwiibind.sh script for pairing a device with BlueZ doesn't work, as the scripts that it needs are no-longer all part of BlueZ.
Adjust the XWiiIface class so that ::Dispatch only returns when there is an event to deal with and make it use poll() internally so that it doesn't use any CPU unless the balance board has sent an event. This stops the wii-scale process using 100% of a CPU core in-between received events by continually calling xwii_iface_dispatch().
Call .clear() (rather than mistakenly calling .empty()) between weighings so that measurements after the first are correct.
Set up a cppcheck target for cmake to run cppcheck against the project's *.cpp files and run this as part of the default build target. Also set the default command-line argument variable values directly instead of via default() to keep cppcheck happy.
Now that the backend is working fairly well again, make the frontend start it rather than having to launch it manually.
By default, input devices can only be directly accessed by root (to prevent snooping on passwords etc). However, as the balance board doesn't transmit any sensitive data we can relax this restriction with a udev rule and stop having to run the backend as root.
Instead of discarding a fixed number of values at the start of weighing (10), calculate the standard deviation of all recorded values and discard values smaller than the mean minus two standard deviations at the start. This automatically compensates for fast or slow stepping on to the balance board and should make for more consistent results.
grunt-contrib-imagemin 0.9.4 depends on a broken version of vinyl-fs, so bump this to 1.0.0 to fix the imagemin Grunt task.
Clean up the debug messages output by the backend and instead make showing a message to the user if the board cannot be found work again. Lots of unrelated changes show under web/public/build due to minor updates to node modules.
|
Hi, when I'll find some spare time (hopefully tomorrow) I'll build it on NixOS so that I can give you the extact dependency list |
|
Had to install:
(so your list seems exhaustive, don't know if pcree is installed with glibmm on ubuntu) To compile i needed to add because of assert no being a member of std |
Compilation was failing under NixOS due to a missing include for <numeric>.
Thanks for taking the time to test compilation under NixOS and listing the packages you needed - happily, I've just checked and the Ubuntu
Good catch - I've pushed an extra commit which adds the missing include. Not sure why that compiles on this machine, presumably pulled in by an include of an include somewhere down the tree.
If you do get the chance to test, let me know the results 🤞 |
|
@ribbons Ok I could test it yesterday, and I can confirm it is working :) The only thing I had to change was the parsed "calibrate" arg. I could not understand why the "calibrate" variable was empty. Changing the json param to "calib" (and changing the js accordingly) it did worked (variable not empty). Changing to "caibrat" worked. Changing to "calibrate" always led to an empty variable... I had not got the time to investigate further (If this post is not clear, let me know and I'll post the edits I've tried) Thanks! |
Great - glad to hear it!
Yes, sorry - I'm not clear on the issue you've been hitting. I've just had a play with setting calibrate to both positive and negative values via |
|
OK i found the problem. It was due to .npmrc, that had
wii-scale:calibrate=
I was editing the package.json, and the calibrate value was being ignored. My fault, fixed now :)
Very positive impression about the new backend :)
Il 20 febbraio 2017 20:23:00 CET, Matt Robinson <notifications@github.com> ha scritto:
…> @ribbons Ok I could test it yesterday, and I can confirm it is
working :)
Great - glad to hear it!
> The only thing I had to change was the parsed "calibrate" arg. I
could not understand why the "calibrate" variable was empty. Changing
the json param to "calib" (and changing the js accordingly) it did
worked (variable not empty). Changing to "caibrat" worked. Changing to
"calibrate" always led to an empty variable... I had not got the time
to investigate further
>
> (If this post is not clear, let me know and I'll post the edits I've
tried)
Yes, sorry - I'm not clear on the issue you've been hitting. I've just
had a play with setting calibrate to both positive and negative values
via `npm config` and it seemed to come through to the backend okay.
Are you hitting the issue in the C++ backend or the node frontend?
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#17 (comment)
--
Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità.
|
|
@nico202 Ah, cool - good work tracking that one down & thanks for your kind words 😄. @sahoahfoa - hope you don't mind me pulling you in on this one, but I was wondering what system you are running on? It would be great to get another data-point if you wouldn't mind compiling this latest code too? |
|
Sure thing. I've been running it on a RasPi and Debian. I'll try it out on a clean install to see if there are any more dependencies needed. Seeing as it is ubuntu based I doubt there are any missing. |
|
Tried it out on my raspi and got an error when I tried to disconnect. The board failed to disconnect. After rebooting and running as root it still failed. I'm running the latest version of raspbian with all packages up-to-date. Edit: The same error occurs on Linux Mint (xfce) but board disconnects. I should mention that my raspi does not have a gui. gdb output This happens around line 34 in BlueZDevice.cpp |
|
I check with the xwiishow as you suggest, and I realize that the board does not show data on the gui neither. So I replace the batteries and voilá, it appears to be working again. So, sorry for bother you. Again thanks for your help. Regards. |
Great - glad it was a straight-forward fix.
Yes, I believe that battery status is available - it is certainly one of the things I'd like to start working on once this PR is merged. |
Okay, have closed #20. Yes, this is ready for reviewing and merging 😄. |
|
Hi @ribbons, May 28 10:42:09 pyre npm[319]: [2017-05-28 10:42:09] [connect] WebSocket Connection 127.0.0.1:8080 v-2 "WebSocket++/0.7.0" /socket.io/?EIO=4&transport=websocket&t=1495968129 101 When I'll have more time I'll try to put together the steps to reproduce this, |
I figured out a way to reproduce this error - clicking twice quickly on the Disconnect button. This fires off two requests to disconnect, the second of which fails while working out the path due to the board having just disconnected. I will try and make some time over the next couple of evenings to see how I can prevent this bug occurring. |
If the 'Disconnect' button is pressed twice quickly, the backend attempts to disconnect the board twice, crashing part-way through the second disconnect when the device cannot be found in the list returned from BlueZ. Resolve this by adding a flag to the XWiiIface class which ignores disconnect requests after the first has been sent.
|
Right, I've just pushed a commit which should fix the issue you ran into @n1zzo, so this PR is back to being ready for review and merge @aelveborn 😄. |
|
Nice work! |
|
I'm having issue building this on the RPi, I get the following error when i try to build, any thoughts? I downloaded your git from here - https://github.com/ribbons/Wii-Scale, if i used the master here then I didn't have any of the files |
From the error message you are getting I'd suspect that you've not checked out the submodules as well, try doing a |
|
Hey ribbons, do you remember that strange error I told you before about the graph, it happends again. As I told you I´m an intensive user of the system, my wife to be more concrete, and the error persist, the graph stop drawing after april 8. I attach below a screen cap just for the record.
any idea how to fix this? |
I'm not that familiar with the front-end code, I suspect @aelveborn would be able to shed more light on the subject, but as it isn't related to the new backend, I'd say it would be a good idea to raise a new issue for it. |
|
Hey @ribbons, do you think your PR are ready to be merged? |
Hey! Yes, all ready to go 👍 |
|
Hey @aelveborn would be nice if you could accept the merge request. |
Due to the newer toolchain and library versions, compilation was failing under Arch Linux. Resolve these issues by: * Setting the socket.io-client-cpp submodule to an updated commit in my fork (until the PR is merged upstream). * Preventing unnecessary compilation of the sioclient_tls target in socket.io-client-cpp which we aren't using and fails with the latest version of OpenSSL.
|
Have just pushed a small update to this PR which fixes compilation of the socket.io client under Arch Linux. |
|
Hi! First of all thank you, I've installed and built everything on rpi3 without any problems. My question is - do I have to turn over the board and press sync button every time? Cause after I click disconnect - I can't connect it again. |
No, you should only need to do that once during the initial pairing with your Pi (outside of the Wii-Scale application). Once you've done that you can just press the balance board button. Have you paired the board with your Pi using the desktop application / widget or |
|
I'm sorry I should've mentioned it, the answer is yes. I have it paired and trusted. |
The application isn't triggering a bluetooth level connect (it is checking for a connected device and connecting to it), so that would make sense. Sounds like your balance board isn't connecting automatically for some reason. I'm slightly fumbling in the dark but according to this link I just turned up: https://github.com/jgeumlek/MoltenGamepad/wiki/Wiimote-Pairing you might find that completely clearing the balance board from |
I understand that, my question is more about workflow. Do you have it always connected (e.g. you are using wall charger) or pushing front button is enough for it to connect automatically? |
Yes, pushing the front button is enough for the balance board to connect automatically. |
Indeed it does! Thank you! |
|
Thanks @aelveborn 😄
Great, glad that fixed the issue for you 👍 |
|
@ribbons np, you did amazing work. Sorry it took so long.. |
Following on from #14, this is a considerably improved version which I think is now much more like something that could actually be merged.
I've addressed the following issues since my original PR:
Disconnectis pressed in the UInpm startalso launch the backend againI've not implemented pairing via the UI as this is available either via the user's desktop environment, or via
bluetoothctlfor headless boxes and only needs to be done once.Dependencies
This is a hopefully complete list of the dependencies required for building under KDE Neon (and other Ubuntu-based distros):
These might be slightly different under Raspberry Pi, but should be broadly similar - unfortunately I don't have a spare Pi I can use for testing at the moment.
Once the dependencies are installed, it should just be a case of following the build steps in the README.