EVmote App

[rpo]

WOW!!
Put's my ESX environment on RaidZ6 11TB usable and 75mbit/8mbit and static IPs kinda sad sounding.

It's been a fun project, and I don't even work in tech. My only expense with it now is a small weekly backup to Amazon's cloud servers which runs about $6/month for 1 TB.

 

[cynix]

Project Cartesia - Launch, Updates and Support

This is the same bug as above. I think I'm close to fixing it. I'll update the thread as soon as I do. Sorry for the downtime. This is why beta is so important, so thanks to ya'll who are going through this with me

- - - Updated - - -



I'm open to it. Not everyone is going to want to clone the source and setup all of the environments needed to host this themselves. In any case, the monthly hosting cost will be more than the price of the "Pro Features"

For the tech geeks, here's the stack:
One Node.js process using express/jade for all web content, including making backend calls to the tesla api
Another Node.js process as a worker that opens up a stream to the GPS for each car and records those positions in the database
A 3 server MongoDB replica set (Primary, Secondary, and arbiter)
New Relic for monitoring, and loggly for log management/debugging
No CI/CD yet, because I'm a busy guy

The node servers currently run on heroku, but I'm currently moving them to docker/google cloud platform.
The mongodb replica set is already running on GCP because all of the hosted mongo environments charge per gig.

I would love to contribute, but I'm a C++ guy and don't know much about these new JavaScript web frameworks

 

[green1]

So an hour ago or less I signed up for an account and tried it, seemed to work on the initial load, but every time I try since I get "Your Tesla is offline. We'll keep searching for it" and it never gets anywhere, this is despite the Tesla App and Visible Tesla both being able to access the car. Bug?

 

[cryptyk]

So an hour ago or less I signed up for an account and tried it, seemed to work on the initial load, but every time I try since I get "Your Tesla is offline. We'll keep searching for it" and it never gets anywhere, this is despite the Tesla App and Visible Tesla both being able to access the car. Bug?

Same bug as above. It's fixed now, so please give it another shot. If it's still not working you may need to go to "My Account" and re-enter your Tesla password (note that there are two different password sections on that page. Your Tesla password is the third section).

For the geeks:
I switched my application monitoring from Ruxit to New Relic a couple of days ago. No biggie. One line of code. Everything looked good, so I moved on and started fixing some other things.
Here's the part that let it slip through: I live in a highrise and my car is parked 3 levels underground. Whenever I test things, I always get an error saying that my car is unavailable because it really is. There's no wifi or LTE down there.
So New Relic does something pretty clever; it intercepts any outbound HTTP requests and injects some tracking code in them so you can track transactions across different services. The problem is that those headers were making the Tesla servers barf. I couldn't figure out why my test code worked, curl worked, wget worked, everything worked EXCEPT for the production site. I ran some diagnostics on the HTTP requests to Tesla and they looked EXACTLY the same. I finally resorted to running a packet sniffer in the data center to see what was REALLY going across the network and saw the new relic headers. Sneaky, sneaky new relic headers.

I removed the one line of code, reported the bug to new relic, and it's fixed. Of course I don't have any application level monitoring anymore, but I'll move it back to ruxit this weekend (because I like being paged in the middle of the night if response times start to get beyond my expectations )

Thanks,
Ryan

 

[green1]

Working now, perfect.

Though I'm not sure what these "mile" things are....

 

[cryptyk]

Id like to host this myself.. I have many TB of space we could use for this, and a fair amount of bandwidth.. A small VMware host and affair amount of ram.. I could whip up a few servers if you wanted to separate out the functions of db, web, etc.

But originally I was speaking of just making this a package I could install in my web server to host just for me.

also, I'd like to participate in your beta if you're taking users still.


also, a while ago I wrote a departure time based charge scheduling script.. Think you could put that in this? It's something people have mentioned time and time again they'd like to see for model s.

If if you want to see how I got it working we could do a google hangout and I can go over my horrible code with you. I'd be happy to share.

Gotcha.

I have the hosting pretty figured out for now. It's running mostly in Google Cloud right now. It's geographically distributed, fully replicated, active/active, and monitored. Hosting is pretty cheap these days and scaling is easy.

The hard part about self hosting is that it's built to handle enterprise traffic and have enterprise uptime (barring stupid code bugs). It's not as simple as dropping a php script in a folder. As just a base configuration, it's spread on 7 different servers: DB_Primary, DB_Secondary, DB_Arbiter, Web1, Web2, Worker1, Worker2. Technically the code could run on a single server, but it would require a lot of fiddling.
I'm already moving it to a series of docker images, so that might be a good way to open-source it for those who want their own instance. You could run 3 containers (DB, Web, Worker) all on a single machine and point them all at each other. I think

It's not the next thing I'll work on, but I'll keep it in my head as I refactor the physical and network architecture to make sure I don't paint myself into a corner for open-sourcing in the future.

The beta is open, so you're welcome to join if you haven't already

Can you clarify what the departure time script is? I'm guessing that would start your car charging at the right time so it's full right before you leave or something?

Thanks!
Ryan

- - - Updated - - -

Working now, perfect.

Though I'm not sure what these "mile" things are....

They're like kilometers, but louder and they're carrying guns.

Normally, it takes the setting from your car, but I have a bug written up against that.

- - - Updated - - -

I have an unlimited 1000/1000 mbps connection, static IP, 25 TB Synology NAS, etc. If it would help get this off the ground, you can use it for free for hosting.

Must be nice.

As far as hosting, I'm pretty set as mentioned above.

Thanks!
Ryan

 

[O-G]

I just tried to sign up. Tried a couple times and get a "connect. 500 error getting vehicle tokens." I have a tesla account but am still a few weeks out getting my MX. Is that the problem?

 

[cryptyk]

I just tried to sign up. Tried a couple times and get a "connect. 500 error getting vehicle tokens." I have a tesla account but am still a few weeks out getting my MX. Is that the problem?

Yah. I don't think you can use any Tesla apps until you take delivery. I could put a better message though

 

[Urgo]

I highly doubt it was a result of using evmote but just wanted to throw this out there in case this caused it in any way. I just signed up for evmote this morning. All I did was honk the horn a couple times and roll the roof back and forth but then went to go for a drive and got an error about the front motor not working in the car and to contact service. They're on their way over here right now with a loaner. I'm guessing it was just an issue with the car (its still brand new, only a little over 300 miles on it) but JUST IN CASE it was caused by something you're doing with the API I wanted to throw up a flag.

What I have seen of the app though looks cool so far lol. Hope I can keep using it

 

[cryptyk]

I highly doubt it was a result of using evmote but just wanted to throw this out there in case this caused it in any way. I just signed up for evmote this morning. All I did was honk the horn a couple times and roll the roof back and forth but then went to go for a drive and got an error about the front motor not working in the car and to contact service. They're on their way over here right now with a loaner. I'm guessing it was just an issue with the car (its still brand new, only a little over 300 miles on it) but JUST IN CASE it was caused by something you're doing with the API I wanted to throw up a flag.

What I have seen of the app though looks cool so far lol. Hope I can keep using it

View attachment 98241

Oh no! I'm sorry to hear that happened to you. As you said, it doesn't have anything to do with evMote. I don't use any APIs other than the same ones the official apps use. Certainly nothing that could disable one of your motors

Thanks,
Ryan

 

[Urgo]

Oh no! I'm sorry to hear that happened to you. As you said, it doesn't have anything to do with evMote. I don't use any APIs other than the same ones the official apps use. Certainly nothing that could disable one of your motors

Thanks,
Ryan

Yep I figured. Just though I'd do my homework. Thanks for the quick reply

 

[rdrcrmatt]

Can you clarify what the departure time script is? I'm guessing that would start your car charging at the right time so it's full right before you leave or something?

Exactly. I used a field which I was able to pull from the charging data which was a time to full in hours. I did a little math in bash and added 30 minutes to it (45 or 60 if I was going to 100% charge) just for some buffer and yea it just watched the clock and when current time = charge start time the script issues the charge start command. I also gave myself an option in the charge script to set how much charge I wanted and what time I wanted to leave.

It would set the requested charge level, let the car charge for 10-15 minutes then read that "time to full value" and schedule the charge.

Also a master switch on the page called charge scheduling (enabled / disabled). I had a few times where I was charging in the wild and it would charge for a few minutes and stop. I couldn't decide if I wanted it persistently on or off, the master switch saying one way or the other worked well for me.

 

[cryptyk]

Exactly. I used a field which I was able to pull from the charging data which was a time to full in hours. I did a little math in bash and added 30 minutes to it (45 or 60 if I was going to 100% charge) just for some buffer and yea it just watched the clock and when current time = charge start time the script issues the charge start command. I also gave myself an option in the charge script to set how much charge I wanted and what time I wanted to leave.

It would set the requested charge level, let the car charge for 10-15 minutes then read that "time to full value" and schedule the charge.

Also a master switch on the page called charge scheduling (enabled / disabled). I had a few times where I was charging in the wild and it would charge for a few minutes and stop. I couldn't decide if I wanted it persistently on or off, the master switch saying one way or the other worked well for me.

Got it. I have a really dumb question though, because I don't charge at home since I live in a high rise with no chargers:
Why do people want this feature?

Why not just set your charge level and plug it in when you get home? What's the advantage of having it finish up its charging just before you leave for work?

 

[green1]

Got it. I have a really dumb question though, because I don't charge at home since I live in a high rise with no chargers:
Why do people want this feature?

Why not just set your charge level and plug it in when you get home? What's the advantage of having it finish up its charging just before you leave for work?

A couple of reasons, but the most common is if your garage isn't climate controlled, charging the battery also conditions the temperature in it, therefore if you leave home immediately after the charge finishes you have a warm battery so you use less energy trying to heat it, you also don't start out with limits on your regen or accel due to the cold.
Another reason is for long trips where you want to charge to 100%, it's not good to leave the battery at 100% for long periods, so people want it to finish charging to that just before they leave to minimize how long it's at 100%.

 

[Andyw2100]

Got it. I have a really dumb question though, because I don't charge at home since I live in a high rise with no chargers:
Why do people want this feature?

Why not just set your charge level and plug it in when you get home? What's the advantage of having it finish up its charging just before you leave for work?

A couple of reasons, but the most common is if your garage isn't climate controlled, charging the battery also conditions the temperature in it, therefore if you leave home immediately after the charge finishes you have a warm battery so you use less energy trying to heat it, you also don't start out with limits on your regen or accel due to the cold.
Another reason is for long trips where you want to charge to 100%, it's not good to leave the battery at 100% for long periods, so people want it to finish charging to that just before they leave to minimize how long it's at 100%.

Adding to what green1 wrote, an additional reason could be wanting to take advantage of lower electricity rates during off-peak hours.

So with that in mind, if you really want to implement rdrcrmatt's functionality in as sleek and complete a way as possible, you'd also want to be able to have a range of times in which that initial charging could take place, so that it's not happening at a higher than necessary electric rate.

As an example: My electricity rates go to the lower rate at 1:00 AM. I might want to schedule my charge at 8:00 or 9:00 PM, to be finished at 6:00 AM the next morning. As I understand rdrcrmatt's script, it would do a short charge at 8:00 or 9:00 PM, when I first attempted to schedule the charge, in order to determine when to start the charge that needed to be complete by 6:00 AM. I'm suggesting a sleeker solution would be for your software to be able to accept as an input that my lower rate runs from 1:00 AM to 7:00 AM, and then know not to start that test charge until, say, 1:15 AM.

Make sense?

 

[rdrcrmatt]

Adding to what green1 wrote, an additional reason could be wanting to take advantage of lower electricity rates during off-peak hours.

So with that in mind, if you really want to implement rdrcrmatt's functionality in as sleek and complete a way as possible, you'd also want to be able to have a range of times in which that initial charging could take place, so that it's not happening at a higher than necessary electric rate.

As an example: My electricity rates go to the lower rate at 1:00 AM. I might want to schedule my charge at 8:00 or 9:00 PM, to be finished at 6:00 AM the next morning. As I understand rdrcrmatt's script, it would do a short charge at 8:00 or 9:00 PM, when I first attempted to schedule the charge, in order to determine when to start the charge that needed to be complete by 6:00 AM. I'm suggesting a sleeker solution would be for your software to be able to accept as an input that my lower rate runs from 1:00 AM to 7:00 AM, and then know not to start that test charge until, say, 1:15 AM.

Make sense?

Excellent point.

The reason I never wrote that into my script is that my off peak was 8p-8a and I'm always gone around 7a. Could have a selection for a off peak time window, then a selector to prefer to charge as cheap as possible or as close to departure as possible.

cryptyk, Thank you so much for being an app developer for the tools we have for our car and actually listening to our input!!!

 

[cryptyk]

Got it. That all makes sense now. It's not something I ever had to deal with because A) I can't install a charger at home and B) I live in San Diego so the weather never gets cold. I never knew the car limited power in cold weather!
That's the first rule of product, though: You are not your customer.

Thanks for the input. I'll add it to the list.

Thanks,
Ryan

 

[Andyw2100]

Excellent point.

The reason I never wrote that into my script is that my off peak was 8p-8a and I'm always gone around 7a. Could have a selection for a off peak time window, then a selector to prefer to charge as cheap as possible or as close to departure as possible.

cryptyk, Thank you so much for being an app developer for the tools we have for our car and actually listening to our input!!!

Thanks!

And yes, your "two selector" idea would be fine, provided that even if one selects to charge as close to departure as possible the software still knows not to simply ignore rates and times, and will still do the test charge at the lower rate and the full charge at the lower rate when it is possible to do so.

There may be some situations in which the test charge would have to be performed at a higher electric rate in order to tell whether or not the full charge would be able to complete fully if it only started once the rate is lower. But there should be many instances where someone can prioritize the departure time, but still have the test charge taking place in the future, when the rates are lower as well.

Another way this might be accomplished would be to allow the user to just set a window during which no charging may occur. In my case, and I expect in many cases, this would work just fine, as I know my car will always be able to complete its charge starting after 1:00 AM, so I would just set a charging window, and the software then would not be allowed to test charge or charge outside that window. If a charge then fails to complete because I didn't allow a large enough window, that would be on me.

 

[Ingineer]

The test charge shouldn't take more than a minute or so, so why not perform it right away? It won't matter rate-wise.

I noticed my car does this when I plug in with a scheduled charge set. It closes the contactor for a few seconds, probably to sample the voltage. (it knows the current from the pilot signal)

 

[rdrcrmatt]

The test charge shouldn't take more than a minute or so, so why not perform it right away? It won't matter rate-wise.

I noticed my car does this when I plug in with a scheduled charge set. It closes the contactor for a few seconds, probably to sample the voltage. (it knows the current from the pilot signal)

I let my script go for 10 minutes. The time to full would fluctuate a bit in the first few minutes and would stabilize around 5 minutes.