Thank you man, there is no competition, that’s open source!
I haven’t received any notification from github, and I just received the first notification from the forum, that’s why I didn’t replied before.
I’ll look into your PR later, I also made some minor edits yesterday, mostly to QLM files.
Thank you!
1 Like
Yeah, github’s notifications aren’t exactly reliable.
I’ve been testing the key thing a bit more today, and it’s not exactly reliable yet. I don’t know if the problem’s in the app or the bluetooth stack though, I recall reading about Bluez being buggy back in the day… But yeah, it’s a start either way, and since it works sometimes we at least know the implementation isn’t completely wrong 
I reviewed and merged your PR, so you’re now officially a contributor 
CI should be building right now version 0.2.5
I was already testing with vehicle proximity, your PR improved what was already there, and yes, it’s unreliable, we need to do some more tuning, but, hey, one week ago the app was still early stage with a shitty UI, I think we’re improving really fast!
1 Like
Indeed!
By the way, you know what would be cool? If we could somehow expose events to Situations! Then it could turn stuff on and off based on actual vehicle/connection status. Maybe we could even develop an actual API that other car-apps could also use.
Don’t know about Situations, but if you fire the events as D-Bus signals, they can be subscribed to in Automagic.
1 Like
Here’s my idea of what the app cover will look like, what do you think @nappa85 ? (and why not others as well)
The “Connected” text obviously needs to be more legible, but it’s mostly an issue with my ambience.
Then later, it will contain the car name along with the silhouette image, and hopefully we can also tint the silhouette with the real car color (if not, we can color the cover background in the car color, I already did this in another app I’m developing - it’s pretty cool, it can be updated on the fly as well). And the cover can also have action buttons, so we could put the Locks/AC/frunk/trunk buttons there.
1 Like
I’m not a graphics guy, I would accept a TUI application as long as it gets the work done 
That doesn’t mean I don’t appreciate your work, the opposite, I really appreciate it, I would never be able to make something similar, you have my blessing, go for it.
My concerns are more on the actual app functions, yesterday I’ve been stuck under the rain, with my toddler son on my arms, because it was not connecting to the car to let me open the door, even if I pulled the handle to wake up the car from deepsleep, I had to take the card key from my wallet to open the doors, but then I have been able to drive without having to use the NFC.
We need a more reliable session, I suspect things get lost in between the boundaries. maybe having logs in the UI could help debug
Yeah, getting the key to work reliably is of course priority #1.
I tried to debug it a bit earlier today, and did find a bunch of cases where the app would hammer Bluez too hard which could be the cause of the dropped connection, though once again, I’m yet to test the changes.
Also one point with implementing the Cover at this point is that it would make it easy to see the connection status at all times - the UI “candy” is just an added bonus (and really easy to do in this day and age thanks to AI).
Keep in mind AI is a yes man and will try to gaslight you. I’ve made the core of the app in Rust because I’m good at it and I’ll be able to review it, and I had catch it red handed multiple times doing things wrong
Yeah, for sure. It also tends to overcomplicate code, like writing a helper function to call another helper function instead of just doing whatever needs to be done. On the other hand it’s great at handling edge cases, and I find that particularly having it write UI is great because it adds animations and accessibility stuff etc. which would otherwise be a pain in the ass to write.
And don’t even get me started on writing documentation. That’s always been the thing I hate in this line of work, but now I simply don’t need to do it.
… anyway. I’m sure we’ll have the key stuff working once we have a little time to focus on it. I had a similar situation as you described the other day - my kids are a bit bigger, but still, it’s extremely akward when you can’t open the doors. I carry my old Android phone all the time now with bluetooth disabled, so I can just turn that back on if our key system refuses to work.
I think I understood the core of the problem: Rust core is a QThread controlled by QML, that means it dies with the UI. But it spawns the cli Go application to talk with Bluetooth. OS probably kills or freezes UI, while the cli probably survives. And that’s why you see we’re hammering BlueZ: when the first QThread dies, and the cli survives, the session is still active, when UI is resurrected a second QThread is spawned, with a second cli, that tried to open a second session, but isn’t able to, because the first one is still active, but nobody is listening to it.
Unfortunately for a week I’ll be far from my pc and won’t be able to work on it
I may, or may not, have fixed it with a onelineer libc command, asking system to send a SIGTERM to the child when the parent dies (Go handles only SIGTERM/SIGINT).
Version v0.2.6 built and ready for testing
1 Like
Has anyone thought about porting the EVMap Android app to Sailfish OS? Not literally porting, but take the library and slap it on top of the MapLibre QML plugin to make an EV charger finder?
Should be relatively simple, there’s probably a .kml file containing all the chargers (probably per country or something) that could just be “slapped onto” a map.
EVMap actually has quite a lot going on with it. It pulls the chargers themselves from one of several different sources, and separate from that, it uses various APIs to get real-time charger status.
1 Like
Ah, ok. Anyway, looks like it’s open source, so it could be ported to sailfish.
I may, or may not, have fixed it with a onelineer libc command, asking system to send a SIGTERM to the child when the parent dies (Go handles only SIGTERM/SIGINT). Version v0.2.6 built and ready for testing
Yeah at least automatic unlocking didn’t get more reliable. Yesterday when I tested, the key only connected after I had unlocked the doors using the card. I’ll see if I can add some logging (perhaps some debug overlay that shows what’s currently going on) when I get a chance.
woop woop… Pop open the champagne, I think I just got the phone key working as it should now.
My test round was like this:
install latest version → walk out to the car and pull the handle → unlocks → close the door and walk around the backyard until the car autolocks → walk back, pull handle → unlocks
also the cover now nicely illustrates whether we can expect the car to unlock when the handle is pulled.
There’s a PR for you to review @nappa85 - sorry for the somewhat big pile of changes, I went through quite many iterations before it finally worked. There’s also logging into a file there, which I guess can be disabled or at least put under a setting that’s disabled by default or something.
2 Likes
Great news! Unfortunately for this week I only have my phone with me, I’ll try to review somehow.
I was thinking to change the connection between the Rust and Go parts from piping to a unix socket, this way it should become more reliable and we should be able to detect when the other part is not listening
^ Sounds like a good idea that’ll probably make it more robust.
And yeah, no need to hurry with the PR, you can check it out once you’re back near your PC
If you want to test it in the meantime though, I made a release of it on my own fork, should be there once github finished building: Release v0.2.9: Release 0.2.9 · Pauligrinder/ElectricEel · GitHub
It seems to work. I copied the keys over from my app instead of creating new ones and it was able to instantly unlock the car.
1 Like