search

aelveborn / Wii-Scale

Turns your Wii Balance Board into a scale and presents your weight on a responsive website. Runs Linux and works on your Raspberry Pi.
http://aelveborn.github.io/Wii-Scale/
GNU General Public License v2.0
116 stars 27 forks source link

Switch back-end from Python to C++ #17

Closed ribbons closed 6 years ago

ribbons commented 7 years ago

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:

I've not implemented pairing via the UI as this is available either via the user's desktop environment, or via bluetoothctl for 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):

sudo apt-get install g++ make cmake cppcheck libboost-all-dev libxwiimote-dev libglibmm-2.4-dev libudev-dev

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.

nico202 commented 7 years ago

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

nico202 commented 7 years ago

Had to install:

gnumake, cmake, pkgconfig, boost, glibmm, pcre, xwiimote, libudev, cppcheck

(so your list seems exhaustive, don't know if pcree is installed with glibmm on ubuntu)

To compile i needed to add #include <numeric>

because of assert no being a member of std The server starts but I cannot try the pairing since I've not my balance board here right now

ribbons commented 7 years ago

Had to install:

gnumake, cmake, pkgconfig, boost, glibmm, pcre, xwiimote, libudev, cppcheck (so your list seems exhaustive, don't know if pcree is installed with glibmm on ubuntu)

Thanks for taking the time to test compilation under NixOS and listing the packages you needed - happily, I've just checked and the Ubuntu libglibmm-2.4-dev package has an eventual dependency on the libpcre3-dev package, so looks like my package guesswork might have paid off.

To compile i needed to add #include <numeric>

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.

The server starts but I cannot try the pairing since I've not my balance board here right now

If you do get the chance to test, let me know the results :crossed_fingers:

nico202 commented 7 years ago

@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!

ribbons commented 7 years ago

@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?

nico202 commented 7 years ago

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: https://github.com/aelveborn/Wii-Scale/pull/17#issuecomment-281162403

-- Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità.

ribbons commented 7 years ago

@nico202 Ah, cool - good work tracking that one down & thanks for your kind words :smile:.

@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?

sahoahfoa commented 7 years ago

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.

sahoahfoa commented 7 years ago

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.

(process:25824): GLib-GObject-CRITICAL **: g_object_set_qdata_full: assertion 'quark > 0' failed
terminate called after throwing an instance of 'std::bad_cast'
  what():  std::bad_cast

gdb output

(process:29874): GLib-GObject-CRITICAL **: g_object_set_qdata_full: assertion 'quark > 0' failed
[New Thread 0x753ff3e0 (LWP 29881)]                                                             
Glib::RefPtr<Gio::DBus::InterfaceInfo>::~RefPtr (this=0x76705248, __in_chrg=<optimized out>)    
    at /usr/include/glibmm-2.4/glibmm/refptr.h:207

This happens around line 34 in BlueZDevice.cpp

ribbons commented 7 years ago

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.

Yeah... Slightly embarrassing. I was getting the same error as you are on Mint, but as it was working okay I wrongly assumed it was some kind of (harmless-ish) library bug. Turns out you are supposed to call Gio::init() before using the giomm library, so it was a bit of luck that it was working at all.

Have just pushed a commit to fix that issue. Fingers crossed it will also resolve the bad_cast exception under Raspbian... Let me know how it goes.

sahoahfoa commented 7 years ago

Good and bad news. No errors on Linux Mint, but unfortunately it still fails on my raspi. It gets to line 40 before the error. I'm almost certain it's a problem with libglibmm-2.4. It looks like Linux Mint is more up-to-date than Raspbian.

terminate called after throwing an instance of 'std::bad_cast'
  what():  std::bad_cast

Linux mint: Package: libglibmm-2.4-dev Version: 2.46.3-1 Depends: libglibmm-2.4-1v5 (= 2.46.3-1), libglib2.0-dev, libsigc++-2.0-dev, pkg-config

Package: libglibmm-2.4-dev Version: 2.42.0-1 Depends: libglibmm-2.4-1c2a (= 2.42.0-1), libglib2.0-dev (>= 2.42.0), libsigc++-2.0-dev (>= 2.2.10), pkg-config

sahoahfoa commented 7 years ago

Installed Version: 2.50.0-1 of libglibmm-2.4-dev and it is now working flawlessly.

ribbons commented 7 years ago

Installed Version: 2.50.0-1 of libglibmm-2.4-dev and it is now working flawlessly.

Phew, you had me worried there for a moment - glad to hear that the updated version works okay. Would you mind sharing the commands you used to build or install version 2.50?

sahoahfoa commented 7 years ago

There was a lot of trial and error involved. I'm not sure if I'll be able to reproduce what I did. A mixed package system is not ideal and potentially system breaking. libglibmm and boost have a lot of dependencies.

These are the commands I essentially started out with:

sudo su
apt-get update
apt-get install g++ make cmake cppcheck libxwiimote-dev libglibmm-2.4-dev libudev-dev
echo 'APT::Default-Release "stable";' > /etc/apt/apt.conf.d/99defaultrelease 
mv /etc/apt/sources.list.d/raspi.list /etc/apt/sources.list.d/stable.list 
echo 'deb http://mirrordirector.raspbian.org/raspbian/ stretch main contrib non-free rpi' > /etc/apt/sources.list.d/testing.list 
apt-get update 
apt-get -t testing install libboost-all-dev libglibmm-2.4-dev
ribbons commented 7 years ago

Hmm, sounds like I need to spin up a copy of Raspbian on my Pi and have a play to see if there is a slightly less heavy way of working around the issue. Only problem is finding a chunk of time when it isn't in use (normally serves as our media center)...

ribbons commented 7 years ago

Probably shouldn't tempt fate, but I think I've finally cracked it. I reproduced the issue under Debian Jessie and have found the solution - unpacking the variant structure returned by GetManagedObjects level-by-level instead of relying on the convenient Glib::VariantBase::cast_dynamic function. This makes the code a bit more verbose, but not by a huge amount.

This should also fix the issue under Raspbian as we know it was glibmm related rather than a Pi specific problem. @sahoahfoa - any chance you have a non-mixed package install of Raspbian you would be able to give this latest version a try on?

sahoahfoa commented 7 years ago

I can spin up a fresh install of Raspbian tomorrow. I've been unsuccessfully trying to get a compiled version of glib and glibmm to work with wii-scale correctly. I'm missing something when configuring cmake to link the correct glib library as glib is installed by default.

sahoahfoa commented 7 years ago

It works flawlessly now! I think this might be ready.

ribbons commented 7 years ago

It works flawlessly now! I think this might be ready.

Great news! Many thanks for your help with the testing.

@nico202 Any chance you could try this (hopefully final) version to make sure we've covered the waterfront of likely glibmm versions?

nico202 commented 7 years ago

@ribbons I do not have internet at home those days, I'll try in a couple of days, bump me if i forget it and forget to update you before the week end

ribbons commented 7 years ago

@ribbons I do not have internet at home those days, I'll try in a couple of days, bump me if i forget it and forget to update you before the week end

@nico202, bump :smile: - or at least I think this is when you wanted me to bump you..?

nico202 commented 7 years ago

Yes this was the perfect bumping time. But still no internet 'till 28/03 :(

I'm sorry for the delay

On 03/24/2017 03:21 PM, Matt Robinson wrote:

@ribbons <https://github.com/ribbons> I do not have internet at
home those days, I'll try in a couple of days, bump me if i forget
it and forget to update you before the week end

@nico202 https://github.com/nico202, bump 😄 - or at least I think this is when you wanted me to bump you..?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/aelveborn/Wii-Scale/pull/17#issuecomment-289035721, or mute the thread https://github.com/notifications/unsubscribe-auth/AH1YDu_LhS-QhwAPJ6-skytm-9ouxgJHks5ro9F8gaJpZM4MEcgD.

ribbons commented 7 years ago

Yes this was the perfect bumping time. But still no internet 'till 28/03 :(

I'm sorry for the delay

No worries - the 28th isn't far off :smile:

Esylias commented 7 years ago

I have a problem with my connected wii board. i got no scale results after i got an successfull sync.

is it possible, that my bluetooth is not compatible, although he connect to board?

ribbons commented 7 years ago

I have a problem with my connected wii board. i got no scale results after i got an successfull sync.

is it possible, that my bluetooth is not compatible, although he connect to board?

I'm not sure - are you running the compiled C++ binary version from this PR, or using the current Python based version (I saw that you also raised issue #19).

P.S. How are things looking with your internet situation @nico202?

franc6 commented 7 years ago

Just FYI: It looks like on Debian Jessie, the user running the back-end needs to either be root or be part of the "bluetooth" group. It took me a while to figure out why the back-end was crashing every time I hit the "Disconnect" button. For reference, there was an uncaught exception, Gio::DBus::Error, when "GetManagedObjects" is called from the BlueZDevice ctor. Inspecting the exception (after modifying the code to catch it) showed it was an access problem, which led me to look at /etc/dbus-1/system.d/bluetooth. Adding my user to the bluetooth group corrected the problem. I suspect modifying that file to allow my user the same permissions as the bluetooth group would also succeed, but that seemed excessive (since the system was installed only to try out this code, I'm trying to make minimal changes; the list of software above is pretty good, but it doesn't account for Jessie having an old version of CMake or for the missing rapidjson, which is a dependency of socket.io-client-cpp).

It might be worth noting that the user should be part of the bluetooth group, and/or modifying the BlueZDevice ctor to catch any DBus-related exceptions, dump the value of what() for the exception. I'd also recommend re-throwing, so the back-end will still terminate, and the error message that gets logged is the most relevant one. Otherwise, it might still throw a std::runtime_error at the end of the ctor, and that message isn't going to help the user figure out how to fix it. :)

Come to think of it, it'd also be nice to terminate the web server if the back-end terminates prematurely. Just be sure the server gets a chance to log the output from the back-end first. :)

Esylias commented 7 years ago

@ribbons i'm using the current release by using "npm start". i think its python.

i will try c++ now

wii-scale@0.0.4

start /home/Wii-Scale node scripts/start.js

Listening on 0.0.0.0:8080 Wii-Scale started

[2017-03-30 22:57:41] [info] asio async_connect error: system:111 (Connection refused) [2017-03-30 22:57:41] [info] Error getting remote endpoint: system:107 (Transport endpoint is not connected) [2017-03-30 22:57:41] [error] handle_connect error: Underlying Transport Error

lokijs loadDatabase : Database not found [2017-03-30 22:57:46] [connect] Successful connection

[2017-03-30 22:57:46] [connect] WebSocket Connection 127.0.0.1:8080 v-2 "WebSocket++/0.5.1" /socket.io/?EIO=4&transport=websocket&t=1490914666 101

I got following error in browser, after clicking "connect": Could not find Wii Balance Board. Make sure that it is paired and connected.

I paired and connected by blutetoothctl and set wii-scale:address.

board info (hcitool info)

   BD Address:  01:2A:19:80:14:C7
   Device Name: Nintendo RVL-WBC-01
   LMP Version: 1.2 (0x2) LMP Subversion: 0x229
   Manufacturer: Broadcom Corporation (15)
   Features: 0xbc 0x02 0x04 0x38 0x08 0x00 0x00 0x00
           <encryption> <slot offset> <timing accuracy> <role switch>
           <sniff mode> <RSSI> <power control> <enhanced iscan>
           <interlaced iscan> <interlaced pscan> <AFH cap. slave>
ribbons commented 7 years ago

Just FYI: It looks like on Debian Jessie, the user running the back-end needs to either be root or be part of the "bluetooth" group. It took me a while to figure out why the back-end was crashing every time I hit the "Disconnect" button. For reference, there was an uncaught exception, Gio::DBus::Error, when "GetManagedObjects" is called from the BlueZDevice ctor. Inspecting the exception (after modifying the code to catch it) showed it was an access problem, which led me to look at /etc/dbus-1/system.d/bluetooth. Adding my user to the bluetooth group corrected the problem.

Good catch - when I was resolving the previous cast issue under Jessie I was running everything as root so didn't pick that up.

I suspect modifying that file to allow my user the same permissions as the bluetooth group would also succeed, but that seemed excessive (since the system was installed only to try out this code, I'm trying to make minimal changes; the list of software above is pretty good, but it doesn't account for Jessie having an old version of CMake or for the missing rapidjson, which is a dependency of socket.io-client-cpp).

Yes, I ended up getting CMake from backports. However, I didn't need to do anything special for rapidjson as this is a git submodule of socket.io-client-cpp - did you do a recursive checkout?

It might be worth noting that the user should be part of the bluetooth group, and/or modifying the BlueZDevice ctor to catch any DBus-related exceptions, dump the value of what() for the exception. I'd also recommend re-throwing, so the back-end will still terminate, and the error message that gets logged is the most relevant one. Otherwise, it might still throw a std::runtime_error at the end of the ctor, and that message isn't going to help the user figure out how to fix it. :)

Yes, that information should definitely go in the Wiki when this PR gets merged. Not sure if it should go in the readme as well though? I've pushed another commit which writes the contents of what() from any Gio::DBus::Error exceptions raised in the BlueZDevice ctor before re-throwing.

Come to think of it, it'd also be nice to terminate the web server if the back-end terminates prematurely. Just be sure the server gets a chance to log the output from the back-end first. :)

Possibly, or should the long term aim be for the back-end wii-scale process to stay running and propagate the error to the user via the web frontend? As these kind of errors are likely to mostly happen while a user is setting up the application and running from the terminal, my feeling would be that implementing either of those solutions would be better left until a later PR?

ribbons commented 7 years ago

@Esylias - what distro are you running?

franc6 commented 7 years ago

Yes, I ended up getting CMake from backports. However, I didn't need to do anything special for rapidjson as this is a git submodule of socket.io-client-cpp - did you do a recursive checkout?

Well, I thought I did, but since I see it clearly listed in the .gitmodules files, I obviously did not. :)

Yes, that information should definitely go in the Wiki when this PR gets merged. Not sure if it should go in the readme as well though? I've pushed another commit which writes the contents of what() from any Gio::DBus::Error exceptions raised in the BlueZDevice ctor before re-throwing.

I see the commit, that's exactly what I was thinking of. :)

Possibly, or should the long term aim be for the back-end wii-scale process to stay running and propagate the error to the user via the web frontend? As these kind of errors are likely to mostly happen while a user is setting up the application and running from the terminal, my feeling would be that implementing either of those solutions would be better left until a later PR?

I'm not sure what's best here. My first thought was to let it run, and just propagate the error to the front end, maybe with a "restart backend" if the problem is bad enough. But then, I've only seen issues when first setting it up, and I've no idea how likely other problems are to arise. Without knowing more, I tend to go for "leave the exceptional case exceptional" and wait to see who complains. But then, I spent a long time at an ISV where "exceptional cases" had to always be handled by a clean exit, so maybe I'm just rebelling a little bit. :)

Esylias commented 7 years ago

@ribbons i'm running debian jessie on rpi

ribbons commented 7 years ago

@ribbons i'm running debian jessie on rpi

In theory it should work - I've tested using Debian Jessie on x86_64 and @sahoahfoa has tested on Raspbian Jessie (which is based on Debian). I'd suggest testing if you can see the board and read weight values from it with the xwiishow utility (from the xwiimote package).

nico202 commented 7 years ago

@ribbons I have interned today! Trying it out, I'll update here Update 1: CMakeLists.txt is missing 2 boost libraries. Fixed:

find_package(Boost REQUIRED COMPONENTS program_options date_time random)

Update 2: new dependency (openssl)

Update 3:

terminate called after throwing an instance of 'std::runtime_error'
  what():  Couldn't find address

I'll look at it tomorrow

Esylias commented 7 years ago

@ribbons i testet now with newest distro from https://github.com/dvdhrm/xwiimote i'm connected to wiiboard and "xwiishow 1" find a balanceboard device. no scale, but an error "cannot read led state" => Screenshot

if i connect to board by bluetoothctl, the out from "hcidump -i hci0" get filled with

ACL data: handle 12 flags 0x02 dlen 8 L2CAP(d): cid 0x0041 len 4 [psm 19] HIDP: Data: Input report

is it possible to make this output human?

ribbons commented 7 years ago

@Esylias

i testet now with newest distro from https://github.com/dvdhrm/xwiimote i'm connected to wiiboard and "xwiishow 1" find a balanceboard device. no scale, but an error "cannot read led state" => Screenshot

I get the LED state error, so that isn't anything to worry about. Do the read values in the balance board section change if you put weight on the board?

Not sure about hcidump - I've not used that tool before.

@nico202 - have you managed to look into the issue any further?

Nauttor commented 7 years ago

Hi Ribbons,

I´m migrating my old Wii-scale version to your version right now on my server (Debian jessie). I encounter several dependencies lost. First of all my jessie cmake version does not work against your code, so I download, compile and install the last cmake version available. After that, when I try to do the cmake it reports that I need to solve several dependencies. In my case: pkg-config cmake-data libboost-all-dev libxwiimote-dev libglibmm-2.4-dev.

After that, all compile correctly. When I run the nom start i get: [2017-04-17 14:36:19] [info] asio async_connect error: system:111 (Connection refused) [2017-04-17 14:36:19] [info] Error getting remote endpoint: system:107 (Transport endpoint is not connected) [2017-04-17 14:36:19] [error] handle_connect error: Underlying Transport Error

I can open the webpage but my balance board does not appear to be paired. I hit the front button and nothing happends, the red button neither. Do you change the pairing procedure? I do as before via bluetoothctl doing: power on, agent on, press red button, scan on, pair with the macaddr, then connenct, then trust. All appears to be fine, but the wii-scale web still refuse to connect.

Did I miss something?

ribbons commented 7 years ago

I´m migrating my old Wii-scale version to your version right now on my server (Debian jessie). I encounter several dependencies lost. First of all my jessie cmake version does not work against your code, so I download, compile and install the last cmake version available. After that, when I try to do the cmake it reports that I need to solve several dependencies. In my case: pkg-config cmake-data libboost-all-dev libxwiimote-dev libglibmm-2.4-dev.

I think I've covered those above in the 'Dependencies' section - from memory, pkg-config gets pulled in by one of the other packages.

After that, all compile correctly. When I run the nom start i get: [2017-04-17 14:36:19] [info] asio async_connect error: system:111 (Connection refused) [2017-04-17 14:36:19] [info] Error getting remote endpoint: system:107 (Transport endpoint is not connected) [2017-04-17 14:36:19] [error] handle_connect error: Underlying Transport Error

I get that error sometimes, think it is due to the order in which the server and backend start. After a few seconds the backend should try to connect again and show [connect] Successful connection. Does that happen for you?

I can open the webpage but my balance board does not appear to be paired. I hit the front button and nothing happends, the red button neither. Do you change the pairing procedure? I do as before via bluetoothctl doing: power on, agent on, press red button, scan on, pair with the macaddr, then connenct, then trust. All appears to be fine, but the wii-scale web still refuse to connect.

As mentioned above, you need to pair the board before using Wii-Scale with the C++ backend. Is the blue light on the balance board lit continuously before you are pressing the 'Connect' button within Wii-Scale?

Nauttor commented 7 years ago

Hi Ribbons,

You have are right as expected :) About the dependencies was just as a reference of what I get, don´t worry about it.

About the [connect] Successful connection. , yes it appears after a while.

About my balance board, it can be quite tricky sometimes to get it paired correctly, but I removed it from the bluetoothctl and did the pairing process from scratch, and now it works. However I find the same error others mention before, when I select connect it works, when select disconnect I get the bad_cast error. I´m doing something wrong or the bug it´s still there?

(process:26867): GLib-GObject-CRITICAL **: g_object_set_qdata_full: assertion 'quark > 0' failed

terminate called after throwing an instance of ' std::bad_cast' what(): std::bad_cast

Just for the record, congrats for your great effort on encounter time to migrate the project. I use the old version tripping the code to make it work on my Jessie long time ago. That remembers me that one of the "fixes" that I wire on the code was an issue I encounter on my board. The software assumes that the calibration can be only positive, however on my balance board the calibration must be -2 kg. It´s and extrange behaivour I know but that´s the case, and the calibration parameter do not accept negative values, because of that I make a dirty fix on the code.

Regards.

ribbons commented 7 years ago

About the [connect] Successful connection. , yes it appears after a while.

Great - once this PR has been merged, that is one of the things I've been thinking should be addressed - probably just by swapping over the order in which the components are started.

About my balance board, it can be quite tricky sometimes to get it paired correctly, but I removed it from the bluetoothctl and did the pairing process from scratch, and now it works. However I find the same error others mention before, when I select connect it works, when select disconnect I get the bad_cast error. I´m doing something wrong or the bug it´s still there?

(process:26867): GLib-GObject-CRITICAL **: g_object_set_qdata_full: assertion 'quark > 0' failed

terminate called after throwing an instance of ' std::bad_cast' what(): std::bad_cast

Great - glad it does at least kind-of-work. A shot in the dark: did you check out the cpp-back-end or the master branch from my fork? I just checked and found that the master branch was a bit behind and didn't include the commit with the fix that Jessie needs. I've just (force push) updated the master branch of my fork, so either that or the cpp-back-end branches should work okay now.

Just for the record, congrats for your great effort on encounter time to migrate the project. I use the old version tripping the code to make it work on my Jessie long time ago. That remembers me that one of the "fixes" that I wire on the code was an issue I encounter on my board. The software assumes that the calibration can be only positive, however on my balance board the calibration must be -2 kg. It´s and extrange behaivour I know but that´s the case, and the calibration parameter do not accept negative values, because of that I make a dirty fix on the code.

Thanks :smile:. Yes, I seem to remember stumbling across that when I was testing the new version. I think (again from memory) that negative calibration should work okay with the C++ backend. Let me know if it doesn't.

Nauttor commented 7 years ago

Hi, you are right, I´m on the master branch. I don´t see any commit on the master branch since February maybe the force update don´t work?, I´ll start from scratch with the cpp-back-end branch and test it out again. I´ll report on my tests.

About the negative values, was the first thing I tried and it crashed the npm start when I set the calibration setup to -2 as is.

Thanks.

Nauttor commented 7 years ago

Hi,

I had download and compile the cpp-back-end branch to test if the disconnect button works on my jessie as you suggest. I'll report on that later.

I had test the calibration to a negative value and that's what I got.

npm config set wii-scale:calibrate -2 npm start

wii-scale@0.0.4 start /opt/Wii-Scale node scripts/start.js

Listening on 0.0.0.0:8080 lokijs loadDatabase : Database not found terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector >' what(): the required argument for option '--calibrate' is missing

If I set the value back to 0 it works again. So, no luck with negative values.

ribbons commented 7 years ago

@Nauttor:

npm config set wii-scale:calibrate -2

If you check ~/.npmrc, your command above actually sets wii-scale:calibrate to an empty value (hence the error). I'm guessing -2 is being interpreted as a switch and then silently ignored (which seems unhelpful of npm).

To actually set the value to -2, use this command instead:

npm config set wii-scale:calibrate -- -2
Nauttor commented 7 years ago

@ribbons

Thanks Matt, that was my fault to no read the output error, as you said it works now beautifully. With the cpp-back-end branch it connects and disconnects fine.

Now that I can pass it to production and remove the old version I want to mention some issues that happens to me in the past with the old version. After a while using it, maybe 2 months or so the graphs appears to be broken and it only shows 3 points. It was strange as in my list I had a the time more than 20 records. I now it's difficult to solve it without having logs or whatever, but I want to mention it because maybe it happens to you before. The only solution I encounter at the time was to delete the user and add other and start from scratch, and it was a shame as I lost my records.

One more question, I don´t know if it use a file to save the records or a db on a single file as rr4jd, but do you know if it could be possible to export the data to a CSV, XLS or other format? If not it would be great to add such function.

Thank for your support.

EDIT: I check the files an all the data are inside the app-data.json file, excuse me, quite obvious.

ribbons commented 7 years ago

Thanks Matt, that was my fault to no read the output error, as you said it works now beautifully. With the cpp-back-end branch it connects and disconnects fine.

Great, glad it works for you.

Now that I can pass it to production and remove the old version I want to mention some issues that happens to me in the past with the old version. After a while using it, maybe 2 months or so the graphs appears to be broken and it only shows 3 points. It was strange as in my list I had a the time more than 20 records. I now it's difficult to solve it without having logs or whatever, but I want to mention it because maybe it happens to you before. The only solution I encounter at the time was to delete the user and add other and start from scratch, and it was a shame as I lost my records.

Probably best to raise it as a separate issue when it happens again & perhaps attach the app-data.json file if you would be happy sharing that with the world.

@nico202 - how are you getting on with debugging the issue you've found - can I do anything to help?

n1zzo commented 7 years ago

Hi, first of all thank you for porting the backend to C++. I'm testing your branch on Raspberry Pi 2 with ArchLinux ARM (kernel 4.9.21-1), I have paired my board with bluetoothctl, and this is my xwiishow list output:

Listing connected Wii Remote devices:
  Found device #1: /sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/bluetooth/hci0/hci0:71/0005:057E:0306.0005
End of device list

When I start the server with the board already connected, and click on the green "connect" button on the web interface, nothing happens and the command line shows the following output:

> wii-scale@0.0.4 start /home/nico/Deploy/wiiscale
> node scripts/start.js

Listening on 0.0.0.0:8080
lokijs loadDatabase : Database not found
Wii-Scale started

[2017-04-25 18:51:51] [info] asio async_connect error: system:111 (Connection refused)
[2017-04-25 18:51:51] [info] Error getting remote endpoint: system:107 (Transport endpoint is not connected)
[2017-04-25 18:51:51] [error] handle_connect error: Underlying Transport Error

[2017-04-25 18:51:56] [connect] Successful connection

[2017-04-25 18:51:56] [connect] WebSocket Connection 127.0.0.1:8080 v-2 "WebSocket++/0.7.0" /socket.io/?EIO=4&transport=websocket&t=1493146316 101

Found Wii Balance Board at: /sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/bluetooth/hci0/hci0:71/0005:057E:0306.0005

terminate called after throwing an instance of 'std::runtime_error'

  what():  Couldn't find address

By digging into your code I saw that this could be due to a missing "address" attribute in the udev node. So I listed the udev attributes for my Balance Board. This is the output of the following command:

udevadm info -a -p /sys/bus/hid/devices/0005\:057E\:0306.0005

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

  looking at device '/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/bluetooth/hci0/hci0:71/0005:057E:0306.0005':
    KERNEL=="0005:057E:0306.0005"
    SUBSYSTEM=="hid"
    DRIVER=="wiimote"
    ATTR{bboard_calib}=="25a7:4c94:0fe1:1871:2c94:5378:16d9:1f4b:3390:5a5c:1dcb:262e"
    ATTR{country}=="33"
    ATTR{devtype}=="balanceboard"
    ATTR{extension}=="balanceboard"

  looking at parent device '/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/bluetooth/hci0/hci0:71':
    KERNELS=="hci0:71"
    SUBSYSTEMS=="bluetooth"
    DRIVERS==""

  looking at parent device '/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/bluetooth/hci0':
    KERNELS=="hci0"
    SUBSYSTEMS=="bluetooth"
    DRIVERS==""
...

So no address attribute on the Balance Board device! This udev bug report could be related!

Sorry for the long comment, please tell me how can I help you in solving this!

aelveborn commented 7 years ago

Awesome work guys! This is so exciting, I'm no C++ programmer but I have done my fair share of C. @ribbons Is this PR ready to be merged or should we merge it to the dev branch as we spoke about before? I'm gonna try to be more active in keeping up with the development, I've had a super hectic year behind me.

aelveborn commented 7 years ago

@ribbons I saw that you included the build folder, that folder should not be version controlled so it would be best to ignore the build folder again, this wont affect the C++ build right? Another suggestion is that I think we should get rid of all copyright notices. Could be hard to keep up since this is a collaboration, what do you think @ribbons ?

ribbons commented 7 years ago

@n1zzo Thanks for your detailed comment, no need to apologise for length - looks to me like you've hit the nail on the head as this is my output for the same command:

  looking at device '/devices/pci0000:00/0000:00:14.0/usb1/1-10/1-10:1.0/bluetooth/hci0/hci0:1/0005:057E:0306.0005':
    KERNEL=="0005:057E:0306.0005"
    SUBSYSTEM=="hid"
    DRIVER=="wiimote"
    ATTR{bboard_calib}=="1754:0866:0669:3835:1e15:0f41:0d34:3f4d:24e1:1627:140a:4666"
    ATTR{country}=="33"
    ATTR{devtype}=="balanceboard"
    ATTR{extension}=="balanceboard"

  looking at parent device '/devices/pci0000:00/0000:00:14.0/usb1/1-10/1-10:1.0/bluetooth/hci0/hci0:1':
    KERNELS=="hci0:1"
    SUBSYSTEMS=="bluetooth"
    DRIVERS==""
    ATTRS{address}=="00:22:4c:65:3f:e5"
    ATTRS{type}=="ACL"

...

I think that most likely explains why we have seen a few testers getting the same error. My gut feeling is that it could be a code change in more recent kernels - what kernel are you running (I'm guessing a pretty recent one as you are using an Arch derivative)? The most recent I've personally tested on is 4.4.0-71-generic under Ubuntu, which isn't that recent.

What I'm a bit unsure of is how to turn the sysfs device path that xwiimote gives us into something that we can cross-reference with BlueZ if the MAC address isn't always exposed. I'll need to sit down and have a proper poke around at the weekend when I get a bit more free time.

Awesome work guys! This is so exciting, I'm no C++ programmer but I have done my fair share of C. @ribbons Is this PR ready to be merged or should we merge it to the dev branch as we spoke about before? I'm gonna try to be more active in keeping up with the development, I've had a super hectic year behind me.

@aelveborn - good to see you back around and glad you like how it is shaping up :smile:.

This PR isn't quite ready for production yet due to the issue that @n1zzo is experiencing (which may also be the same one as @nico202 and @Esylias are experiencing, but they've gone a little quiet). I don't have time to give this a proper look until the weekend, but I will push a few things around then and see if I can crack it.

@ribbons I saw that you included the build folder, that folder should not be version controlled so it would be best to ignore the build folder again, this wont affect the C++ build right?

Do you mean the web/public/build folder? I only included the updated files as there were already files committed under there - it would be my preference to exclude the built files but I guessed this was to allow people to just run with the checked-out code. If that is what you mean and if you'd have the time add a commit to remove the folder before the weekend it would make it easy for me to rebase this PR :smile:. Otherwise, I can remove it as part of this PR. If I've totally got the wrong end of the stick then let me know!

Another suggestion is that I think we should get rid of all copyright notices. Could be hard to keep up since this is a collaboration, what do you think @ribbons ?

Something that has worked well for me on one of my projects (although I've not had as many contributors as I'd like!), is making the copyright in each file just a date range and then maintaining a simple list of authors in a separate file. I think that this is something that a number of larger projects follow too.

Hope this all makes sense - have written it in a bit of a rush!

ribbons commented 7 years ago

Bump :wink:. Had a thought earlier how we can work around the missing address value, so I'll aim to implement that tomorrow.

nico202 commented 7 years ago

@ribbons Hi, I still could not figure out why I get the error. The parameter path in XWiiIface::XWiiIface(std::string path) init holds the right /sys/device path. But it can't read the address nor product nor other properties. I don't think it'a a matter of permissions, since i can read the files in the path