Flowsync 2.6.2 comes with new QT library. The hook doesn't seem to be compatible anymore.

[roesassi]

The new Flowsync update installed a new QT5 library and it does not seem (at least on my PC) to be compatible with the hook (when FS starts, some other parts of the QT library do not find an entry point in the DLL replaced by Bipolar).

[pcolby]

Interesting! I don't have my Windows or OSX machines handy to test right now (will have tomorrow).

Can you see what version of Qt the new FlowSync is using? (should be able to tell from the DLL properties).

It's probably just going to be a matter of re-applying the hook patch to the new Qt version.

[roesassi]

Absolutely. The new QT5Network.dll claims to be version 5.5.1.0. Quite a jump forward with respect to 5.1.1.0.

[pcolby]

Thanks! Interestingly, FlowSync 2.6.2 for OSX is still using Qt 5.1.x. So the Qt update appears to be Windows-only for now.

[Squirell1]

Will the change be a bigger one? It is "in work"! for several days.
Do you think it will work? Isn't it better, if possible, to have a different method without the hook to be prepared for next QT change?

[pcolby]

Hi @Squirell1,

Will the change be a bigger one? It is "in work"! for several days.

Not really. Its probably quite a small change, and in fact probably already done. I'm just having trouble finding time to test it out on a Windows machine in between a very busy full-time job and family.

If you're willing to help test, the probably-working Hook is already available from the AppVeyor continuous integration service Bipolar uses for Windows builds:

• https://ci.appveyor.com/project/pcolby/bipolar/build/hook-183/artifacts

You can download the Qt5Network.dll file from there, and copy it to your FlowSync installation (I'd recommend backing up / renaming the existing file first). The updated hook does not require any changes to the Bipolar app itself, so you can still use either:

• the latest official release (0.4.0); or
• the latest Windows CI build (0.4.1-164; or
• whatever version of Bipolar you already have installed (assuming its not really old).

Do you think it will work?

I'm 99% certain the approach will continue to work as it always had. Realistically, the only things that could break it permanently are:

• Polar using some application-level encryption (ie with-in their code, not just Qt's TLS support) - this would be particularly tricky for them given their use of Google Protocol Buffers; or
• Polar switching to a commercial Qt license, then either modifying the Qt5Network.dll in an incompatible way and/or statically linking - both of which are effectively forbidden by the LGPL they're currently enjoying (unless they open-source the application, which is highly unlikely to ever happen).

I'm about 80% certain the CI build hook above will work as-is, with no further work required. But until its tested, I can't be certain.

Isn't it better, if possible, to have a different method without the hook to be prepared for next QT change?

Its definitely worth looking at, but as to whether or not it's better - that depends on a whole lot of considerations. What one user considers better, is not necessarily better for other users - it depends, for example, on your usage patterns, the platforms you use, you're sensitivity to delays, and how much money you're willing to invest.

Having said that, there are a number of alternatives already available, including the v800_downloader project, and exports from the flow.polar.com website itself. If you haven't already, you might want to have a look over the list at http://www.dcrainmaker.com/tools or similar lists elsewhere.

I'm definitely open to other approaches. But so far, the Qt5Network.dll hook is the only feasible approach I'm aware of for working with (not around) FlowSync. For completeness, the only other approach for working with FlowSync that I've managed to prove, is to install a local proxy, install a new trusted self-signed SSL certificate for that proxy, and redirect all www.remotepolar.com requests on the host to that proxy. That works, but its a much uglier solution than the Qt hook, with serious security concerns and fragility.

Cheers.

[roesassi]

Dear @pcolby
I tested the new Qt5Network.dll file and it worked fine for me (Windows 7 64 bit).
Thanks

[Squirell1]

Hi Paul,
thank you for the new hook dll - it's fine for win8 64bit.
Cheers Thomas

[pcolby]

Thanks @roesassi and @Squirell1! 😄

I'll release the new hook, and update the master branch to include it in the next Bipolar release, which should be available from AppVeyor later today, and Github Releases later this week.

Cheers.

[pcolby]

The updated Windows installer with the new hook is now available from CI - https://ci.appveyor.com/project/pcolby/bipolar/build/master-192

Official release will come soon... need to sort out OS X build first.

[roesassi]

Thanks @pcolby
just out of curiosity, given what you understood of the communication between Flow and a Polar V800, would it be possible to use the hook to save also the Training targets while they are uploaded from Flow to the device? Would it be difficult or it is at reach with a bit of work (which I might try to do, in case)?
Thanks again.

[pcolby]

would it be possible to use the hook to save also the Training targets while they are uploaded from Flow to the device?

Probably. In principal, the same hook could capture data in the opposite direction, and as long as its in a format we can parse, it should be possible to use it. Just curious... why would you want that data?

Would it be difficult or it is at reach with a bit of work (which I might try to do, in case)?

I would think capturing the raw data would be pretty easy. Parsing it is likely to be only moderately difficult, but very time consuming, with a lot of slow change-sync-check cycles.

Can you tell me exactly what sort of "target" data you're interested in - there's a few different types in the V800 data already. For example, each activity session records some targets for the session - these are captured by Bipolar already, but not used for anything.

[roesassi]

Thanks for the answer.

Just curious... why would you want that data?

I am a long time user of Polar devices (as many other people using bipolar I think) and in the last several years I used to program my running training targets with phased exercises in a RS800, first, and a RS800CX next.

After buying the V800 a couple of months ago, while happy about the device itself, I realized that I have three major problems with it:

• PolarFlow does not offer the level of detail I was used to in Polar ProTrainer (and this is the reason I am an happy user of Bipolar).
• The device itself lacks information in laps when compared to RS800/RS800CX (and information related to phases is only available on Flow).
• The **bigger problem** however is the lack of programmability for exercises. Phased targets in Flow are a very reduced version of what was possible and I have been training with for the last 7/8 years. For example, it only has a very reduced set of velocities (and HR) phases and many exercises are not anymore possible. Given the fact that I bought the device for training, this was a major (and unexpected) disappointment. I opened several requests to Polar to have at least manual limits for phases, so to be able to better fine tune them, but they keep postponing it. So I reasoned that maybe the device itself is capable of more programming capabilities than what supported by Flow, or at least it would be a path to test. My idea is to try to understand the training target format which is uploaded. Given how conservative Polar is, it might be even similar to the pdd file exercise structure. Such a tool would then permit to program the device to Linux users (a sort of V800 uploader).

Best

[pcolby]

Released - https://github.com/pcolby/bipolar/releases/tag/v0.5.0