FarDriver app bug? Client ID 000000 prevents unbind on previously bound controllers

[c.brod]

I’m hoping someone here has seen this before, because I’m completely stuck and this does not seem like a normal bind/unbind issue.

App version 2.8.3. Controllers are YQ72280 and ND96680. Both were originally bound as owner to my phone. At this point, both controllers now show Client ID = 000000 in the app.

What I’ve tried so far:

• New FarDriver account (new email)
• Second phone
• App reset / re-login (email + verification code works fine)
• Three different Bluetooth modules

Same behavior every time:

• Client ID stays 000000
• Cannot unbind
• Controller password is rejected
• App gets stuck bouncing between Connected / Unconnected

Yesterday I experienced a strange, non-reproducible event. After extensive connect/disconnect cycling, including switching between nRF Connect and the FarDriver app on my original Pixel 7 Pro, the app briefly established a real connection with a non-zero Client ID (appeared almost random). Despite being logged into the app under my original owner email and using the originally bound phone, the app identified me as not the owner and allowed me to initiate the 20× e-brake unbind process. This progressed to the countdown / “sending email” stage, but no email was ever sent. After disconnecting, restarting the app, and reconnecting, the controller immediately reverted back to Client ID 000000, and I have been unable to reproduce this behavior since.


At this point I’m trying to figure out whether this is:

• A known app bug
• A server/account-side problem
• Or something specific to certain phones / OS versions

If anyone has dealt with the 000000 client ID situation or knows a way to force a proper rebind/unbind (firmware, server reset, older app version, etc.), I’d really appreciate the insight.

 

[dominik h]

I have nearly the same problem since 6 months, but mine can still be bound to the phone.
After the "error" it is shown as slave and I can not change current or other nececary things anymore.
Also shows Client ID 000000.
Reset bound with unplugging Halls or brake switch was not possible.

 

[c.brod]

This sounds unfortunate. It sounds like I'm on the bad side of the tracks with this issue. What doesn't make any sense to me is that I would be getting the same null user ID when using two separate phones and trying two different controllers. Both controllers as I mentioned were previously working with my device system

 

[amberwolf]

If the app has to talk to some external server somewhere to work, then I'd bet the problem is with the server itself, or with your connection to it. That is most likely an issue between you and the server, or something where they have firewalled the server against things like the massive AI bot problems and caused a problem with allowing their app thru, or the bots themselves (or some other thing) are crashing or otherwise impeding the server's ability to do what the app needs it to do. So the app doesn't get the response required to let your system work, and so nothing happens.

If the app doesn't require talking to some external server, then none of that applies.

But I expect that it does, because of the email thing--it would require some form of email server, at minimum, to exist somewhere, that the app would have to contact to tell it to send one. While an email server could be included in the app itself, it would have to be able to contact and use an email relay somewhere, and if the one it is programmed to use isn't working or is blocked by something, overloaded, etc. (which happens often to open relays because of spammers), it wouldn't be able to send that email to reset things.

If the app requires contacting a server to translate info from the controller and app into a user id, then it would just show the default (probably zero) if it can't get the info from the server.

You can test for internet connectivity comms the app is using by installing a firewall on the device you're running the app on, and setting it to allow all traffic but to log everything from that app, and review the log after using the app. That won't fix anything, but it will give you the addresses of the places it's trying to contact, which you can then use other tools to try to contact and see if there is a problem between you and it, and if there is any way to relay around that problem.

 

[and whatnot]

Ever since they made all that binding, ID, code, mail stuff in the Fardriver app necessary for it to change settings I went back to version 2.4.9 and will simply never update. It left me stranded to often.

 

[c.brod]

If the app has to talk to some external server somewhere to work, then I'd bet the problem is with the server itself, or with your connection to it. That is most likely an issue between you and the server, or something where they have firewalled the server against things like the massive AI bot problems and caused a problem with allowing their app thru, or the bots themselves (or some other thing) are crashing or otherwise impeding the server's ability to do what the app needs it to do. So the app doesn't get the response required to let your system work, and so nothing happens.

If the app doesn't require talking to some external server, then none of that applies.

But I expect that it does, because of the email thing--it would require some form of email server, at minimum, to exist somewhere, that the app would have to contact to tell it to send one. While an email server could be included in the app itself, it would have to be able to contact and use an email relay somewhere, and if the one it is programmed to use isn't working or is blocked by something, overloaded, etc. (which happens often to open relays because of spammers), it wouldn't be able to send that email to reset things.

If the app requires contacting a server to translate info from the controller and app into a user id, then it would just show the default (probably zero) if it can't get the info from the server.

You can test for internet connectivity comms the app is using by installing a firewall on the device you're running the app on, and setting it to allow all traffic but to log everything from that app, and review the log after using the app. That won't fix anything, but it will give you the addresses of the places it's trying to contact, which you can then use other tools to try to contact and see if there is a problem between you and it, and if there is any way to relay around that problem.

I appreciate you taking the time to respond. I suspected this is a me/backend issue, and this seems like the most obvious answer. I have emailed Sia/FarDriver with the long shot hope of seeing if they can check their backend. I have an ND96180 (new in box), two ND96680 (one new in box, the other is the device in question), a ND72680 (new in box), YQ72280 (the other device in question). And now I am worried about trying to use the new ones on my current tech network. I will try to follow your advice with some of those diagnostic steps you suggested as well.

One thing of interest (I explained this in the original post, I should have elaborated - will update post): Yesterday, while I was getting frustrated, I some how managed to make a true (non-owner) connection with the controller using the originally bound phone (Pixel 7 Pro). I was using nFR Connect on my phone, and playing around with connecting and binding. I would then switching back to the FD app and attempting to connect then abruptly turning off the ignition, did this a couple of times. There was a real connection made, but I was not the "owner" (even though I was logged in under the my original owner's email and using original stated android phone). This allowed me to start the x20 brake unbinding process, of which led me to the countdown/waiting for email stage. No email was sent. I disconnected and tried to reconnect and ended up back at the 0000000 client id...I have not been able to reproduce my process.


If there is no remedy to this issue, and if no one has experienced this, then how should I move forward with different controllers? I feel I need a new protocol, otherwise I have thousands of perfectly good hardware that I cant use? Makes no sense.

 

[c.brod]

Ever since they made all that binding, ID, code, mail stuff in the Fardriver app necessary for it to change settings I went back to version 2.4.9 and will simply never update. It left me stranded to often.

Interesting. In my response to the reply earlier I stated I have a handful of new controllers. I should try using your suggested apk version and see if I can actually use my stuff upon initial setup. Unfortunately I down graded to 2.4.7 and am getting the same issue with the previously bound controllers.

 

[amberwolf]

If the app writes data to the controller giving it some required minimum version to handshake with, or actually updates the controller firmware to one that requires a newer app version, then you can't go back without being able to wipe and reset the controller back to original, too. It is possible the firmware is designed so it can't be downgraded with a normal update procedure.

That's a common enough thing with other types of devices...

In that event you'd have to get inside the controller and use an MCU-specific flash tool and procedure to update firmware; I don't know what that would be for that specific MCU / controller, but you could look at the various open-source firmware threads for other controllers to get the general procedure and see if it can be adapted to your hardware, using whatever firmware files you can locate for your hardware. You might even be able to use the procedure to read out the firmware from an "unbricked / unlocked" controller of the same hardware version as yours, and then flash that to yours--but if the hardwares don't match, the firmware could permanently brick yours. :/

 

[dominik h]

Also tried to downgrade, even back to 1.5.4, but had no luck.
I have a 721800 a 72680 a 72450 a 96850 and a 96100 and would also like to get this problem solved.
Bought a few of them used, so will not get much support for them.
Both of the 96V versions are bought from Siaecosys, but they are not installed at the moment.
I will try them during the next weeks and will see if I get the same problem.

 

[c.brod]

Also tried to downgrade, even back to 1.5.4, but had no luck.
I have a 721800 a 72680 a 72450 a 96850 and a 96100 and would also like to get this problem solved.
Bought a few of them used, so will not get much support for them.
Both of the 96V versions are bought from Siaecosys, but they are not installed at the moment.
I will try them during the next weeks and will see if I get the same problem.

Sorry to hear that you are in the same boat. I wonder how common this issue is? Please let me know what steps you take with the new controllers. If I am processing everything it sounds like the brand new controllers that I will be setting up will be bound only with an OLDER apk version. I hope that will solve the issue.

I am also going to reach out to some people to see about flashing older firmware to the controller. But the problem is it cannot be flashed using the BLE connection. I am guessing it will have to be done via serial.

 

[c.brod]

If the app writes data to the controller giving it some required minimum version to handshake with, or actually updates the controller firmware to one that requires a newer app version, then you can't go back without being able to wipe and reset the controller back to original, too. It is possible the firmware is designed so it can't be downgraded with a normal update procedure.

That's a common enough thing with other types of devices...

In that event you'd have to get inside the controller and use an MCU-specific flash tool and procedure to update firmware; I don't know what that would be for that specific MCU / controller, but you could look at the various open-source firmware threads for other controllers to get the general procedure and see if it can be adapted to your hardware, using whatever firmware files you can locate for your hardware. You might even be able to use the procedure to read out the firmware from an "unbricked / unlocked" controller of the same hardware version as yours, and then flash that to yours--but if the hardwares don't match, the firmware could permanently brick yours. :/

I am going to look into downgrading the firmware.

 

[dominik h]

You can flash the Firmware with the Bluetooth App. I have done it two or three years ago. I got the new version from Siaecosys.
They sold me the 96850 with a 90V upper voltage limit. After the Upgrade I could run it up to 122V.
Only ran it for a few minutes, because I first installed the nd72680 in my scooter with a 5kW motor and later upgraded to the 721800 with a 10kW QS273.

 

[c.brod]

You can flash the Firmware with the Bluetooth App. I have done it two or three years ago. I got the new version from Siaecosys.
They sold me the 96850 with a 90V upper voltage limit. After the Upgrade I could run it up to 122V.
Only ran it for a few minutes, because I first installed the nd72680 in my scooter with a 5kW motor and later upgraded to the 721800 with a 10kW QS273.

Okay, so the next question is can I flash via BLE when the controller is experiencing my issue, client id 0000000. Meaning can we flash our controllers without being the "owner"?

 

[dominik h]

If I would have written the software, this would shure not be possible.

I think it is not possible when you have Client ID 00000, but I have not tried it yet, because the nd721800 I would like to get back under my control is more than three years old and I never found a newer firmware for it. I searched a few times when I still had access to the controller, because I wanted to change the the regenerative braking behavior to how it was working on the newer ND72680.
My 721800 supports only fixed regen current, the 72680 has fully variable regen set with the throttle turn back speed.

 

[c.brod]

okay, well

If I would have written the software, this would shure not be possible.

I think it is not possible when you have Client ID 00000, but I have not tried it yet, because the nd721800 I would like to get back under my control is more than three years old and I never found a newer firmware for it. I searched a few times when I still had access to the controller, because I wanted to change the the regenerative braking behavior to how it was working on the newer ND72680.
My 721800 supports only fixed regen current, the 72680 has fully variable regen set with the throttle turn back speed.

Okay, I have no choice but to try and I will report back. In the meantime when I get my new controller up, I am going to make sure I use and old version of the apk (you said which versions did not use binding?)

 

[dominik h]

I think binding started around 2.3

 

[c.brod]

If the app writes data to the controller giving it some required minimum version to handshake with, or actually updates the controller firmware to one that requires a newer app version, then you can't go back without being able to wipe and reset the controller back to original, too. It is possible the firmware is designed so it can't be downgraded with a normal update procedure.

That's a common enough thing with other types of devices...

In that event you'd have to get inside the controller and use an MCU-specific flash tool and procedure to update firmware; I don't know what that would be for that specific MCU / controller, but you could look at the various open-source firmware threads for other controllers to get the general procedure and see if it can be adapted to your hardware, using whatever firmware files you can locate for your hardware. You might even be able to use the procedure to read out the firmware from an "unbricked / unlocked" controller of the same hardware version as yours, and then flash that to yours--but if the hardwares don't match, the firmware could permanently brick yours. :/

Hey there again. So I now have the same issue with a third controller, which compelled me to start digging into your suggestion even more. Ive have been monitoring the data that the FarDriver app sends in and out using PCAPdroid. There is info coming back from the server, I have TCP Tx/Rx activity with the iot.fardriver.com server. I have no experience with traffic but this leads me to believe that I do not have a connection issue...