A guy from Switzerland has a working homelink. I'll have to ask him how he managed to successfully pair it. Von: ovmsdev-bounces@lists.teslaclub.hk [mailto:ovmsdev-bounces@lists.teslaclub.hk] Im Auftrag von Pierre Uhl Gesendet: Samstag, 12. Mai 2012 13:39 An: 'OVMS Developers' Betreff: Re: [Ovmsdev] Car firmware: 1.2.5 Re Homelink The Homelink in Europe is disabled, because the frequency in Europe is not the same like in the US (FCC regulation?). Von: ovmsdev-bounces@lists.teslaclub.hk [mailto:ovmsdev-bounces@lists.teslaclub.hk] Im Auftrag von Mark Webb-Johnson Gesendet: Samstag, 12. Mai 2012 13:22 An: OVMS Developers Betreff: [Ovmsdev] Car firmware: 1.2.5 I've committed to github car firmware v1.2.5. Changes since v1.2.2 include: * Support multiple vehicle configurations - TeslaRoadster and VoltAmpera * New LED indication scheme, and net driver tidy-ups * Auto-support Tesla Roadster v1.5 cars * Issue #38 - Prevent user from locking car if car is ON * Issue #39 - Alert (SMS/PUSH) if trunk is opened while in valet mode Please don't get too excited - this doesn't support Volt/Ampera yet - we're just laying the ground work for that support, as some European developers are about to start work on it. I don't think this release will make it to end-users in its current form. I'm still working on some features to go in, including: 1. Drive logging 2. Charge logging 3. Timed (delayed) charging mode commands 4. Timed charging status feedback 5. Complete-charging-by charging mode 6. Cooldown 7. Moving digital speedo out of experimental and make it available in production units Items [1], [2] and [3] are relatively easy and what I'm working on now. Item [4] is tricky because we haven't found the status update message on the bus yet. Still looking. Item [5] needs the algorithm and lookup table. Item [6] is easy to do, but needs the thresholds defined (what battery temperature to cooldown from, what battery temperature to stop cooldown at, and what current/voltage to use for cooldown). Item [7] seems reasonable now, given the number of cars now using the digital speedo feature and the complete lack of issues seen with it. I notice there was some discussion on the TMC forum about homelink control. That would be pretty easy to do, but we don't have homelink modules here in Hong Kong, and I don't have the can bus codes. They are probably easy to find on ID#102. If someone with a usb-can and a homelink adaptor wants to get the codes, I'm very willing to put them in. It certainly is a cool feature. So, I'm not sure what will make it into what release, when. This v1.2.5 release is definitely developers-only, and intended to check stability of the modem driver revisions and usability of the new LED feedback scheme. It is fully backwards-compatible with v1.2.2, and you can upgrade/downgrade firmware as you need. It is in my car now, and seems to be ok. I would be grateful if developers with some time could try it out and let me have feedback on overall stability and usability of the new LED indication scheme. I've got a little youtube video demonstrating this: http://www.youtube.com/watch?v=MdsB8qK6beY The new LED indication scheme is as follows: 1. When first powered on, the red led stays on, and the green led blinks the version of firmware in the module (e.g.; 1, 2, 5). After that, it enters normal mode. 2. In normal mode, the green led is used to indicate the state, and the red led is used to indicate the last error. 3. If the modem needs to be reset, both red and green leds are turned on for the couple of seconds it takes to reset the modem. The following states are defined: // LED MODES #define NET_LED_WAKEUP 10 // Attempting to wake up the modem #define NET_LED_INITSIM1 9 // Checking SIM card insertion status #define NET_LED_INITSIM2 8 // Checking SIM card PIN status #define NET_LED_INITSIM3 7 // Initialising modem #define NET_LED_COPS 6 // COPS initialisation #define NET_LED_NETINIT 5 // GPRS NET initialisation #define NET_LED_NETAPNOK 4 // GPRS APN is OK, final init #define NET_LED_NETCALL 3 // GPRS Network call #define NET_LED_READY 2 // READY state #define NET_LED_READYGPRS 1 // READY GPRS state The normal behavior is it will start at 10 green blinks and count down to 2 (GSM only) or 1 (GPRS). If GPRS lock is lost, but GSM is still up, the green will blink 1. The followed error codes are defined: // LED ERRORS #define NET_LED_ERRLOSTSIG 1 // Lost signal #define NET_LED_ERRMODEM 2 // Problem communicating with modem #define NET_LED_ERRSIM1 3 // SIM is not inserted/detected #define NET_LED_ERRSIM2 4 // PIN lock on the SIM #define NET_LED_ERRCOPS 6 // COPS GSM lock could not be obtained #define NET_LED_ERRGPRSRETRY 7 // Error (maybe temp) during GPRS init #define NET_LED_ERRGPRSFAIL 8 // GPRS NET INIT failed The error code is cleared (red led turned off) once everything is ok. Regards, Mark.
Thank you all for working on this. I'm just an end user so can't contribute much more than comments but am looking forward to the cool down feature. I am curious though, does anyone have evidence that the cool down feature in beneficial? If so, I wonder why this is something Tesla never implemented. Thanks. David Sent from my iPad On May 12, 2012, at 9:33 AM, "Oliver Weidmann" <oliver@sdds.ch> wrote:
A guy from Switzerland has a working homelink. I’ll have to ask him how he managed to successfully pair it…
Von: ovmsdev-bounces@lists.teslaclub.hk [mailto:ovmsdev-bounces@lists.teslaclub.hk] Im Auftrag von Pierre Uhl Gesendet: Samstag, 12. Mai 2012 13:39 An: 'OVMS Developers' Betreff: Re: [Ovmsdev] Car firmware: 1.2.5
Re Homelink
The Homelink in Europe is disabled, because the frequency in Europe is not the same like in the US (FCC regulation?).
Von: ovmsdev-bounces@lists.teslaclub.hk [mailto:ovmsdev-bounces@lists.teslaclub.hk] Im Auftrag von Mark Webb-Johnson Gesendet: Samstag, 12. Mai 2012 13:22 An: OVMS Developers Betreff: [Ovmsdev] Car firmware: 1.2.5
I've committed to github car firmware v1.2.5.
Changes since v1.2.2 include:
Support multiple vehicle configurations - TeslaRoadster and VoltAmpera New LED indication scheme, and net driver tidy-ups Auto-support Tesla Roadster v1.5 cars Issue #38 - Prevent user from locking car if car is ON Issue #39 - Alert (SMS/PUSH) if trunk is opened while in valet mode
Please don't get too excited - this doesn't support Volt/Ampera yet - we're just laying the ground work for that support, as some European developers are about to start work on it.
I don't think this release will make it to end-users in its current form. I'm still working on some features to go in, including:
Drive logging Charge logging Timed (delayed) charging mode commands Timed charging status feedback Complete-charging-by charging mode Cooldown Moving digital speedo out of experimental and make it available in production units
Items [1], [2] and [3] are relatively easy and what I'm working on now.
Item [4] is tricky because we haven't found the status update message on the bus yet. Still looking. Item [5] needs the algorithm and lookup table. Item [6] is easy to do, but needs the thresholds defined (what battery temperature to cooldown from, what battery temperature to stop cooldown at, and what current/voltage to use for cooldown).
Item [7] seems reasonable now, given the number of cars now using the digital speedo feature and the complete lack of issues seen with it.
I notice there was some discussion on the TMC forum about homelink control. That would be pretty easy to do, but we don't have homelink modules here in Hong Kong, and I don't have the can bus codes. They are probably easy to find on ID#102. If someone with a usb-can and a homelink adaptor wants to get the codes, I'm very willing to put them in. It certainly is a cool feature.
So, I'm not sure what will make it into what release, when.
This v1.2.5 release is definitely developers-only, and intended to check stability of the modem driver revisions and usability of the new LED feedback scheme. It is fully backwards-compatible with v1.2.2, and you can upgrade/downgrade firmware as you need.
It is in my car now, and seems to be ok. I would be grateful if developers with some time could try it out and let me have feedback on overall stability and usability of the new LED indication scheme.
I've got a little youtube video demonstrating this:
http://www.youtube.com/watch?v=MdsB8qK6beY
The new LED indication scheme is as follows:
When first powered on, the red led stays on, and the green led blinks the version of firmware in the module (e.g.; 1, 2, 5). After that, it enters normal mode. In normal mode, the green led is used to indicate the state, and the red led is used to indicate the last error. If the modem needs to be reset, both red and green leds are turned on for the couple of seconds it takes to reset the modem.
The following states are defined: // LED MODES #define NET_LED_WAKEUP 10 // Attempting to wake up the modem #define NET_LED_INITSIM1 9 // Checking SIM card insertion status #define NET_LED_INITSIM2 8 // Checking SIM card PIN status #define NET_LED_INITSIM3 7 // Initialising modem #define NET_LED_COPS 6 // COPS initialisation #define NET_LED_NETINIT 5 // GPRS NET initialisation #define NET_LED_NETAPNOK 4 // GPRS APN is OK, final init #define NET_LED_NETCALL 3 // GPRS Network call #define NET_LED_READY 2 // READY state #define NET_LED_READYGPRS 1 // READY GPRS state
The normal behavior is it will start at 10 green blinks and count down to 2 (GSM only) or 1 (GPRS). If GPRS lock is lost, but GSM is still up, the green will blink 1.
The followed error codes are defined: // LED ERRORS #define NET_LED_ERRLOSTSIG 1 // Lost signal #define NET_LED_ERRMODEM 2 // Problem communicating with modem #define NET_LED_ERRSIM1 3 // SIM is not inserted/detected #define NET_LED_ERRSIM2 4 // PIN lock on the SIM #define NET_LED_ERRCOPS 6 // COPS GSM lock could not be obtained #define NET_LED_ERRGPRSRETRY 7 // Error (maybe temp) during GPRS init #define NET_LED_ERRGPRSFAIL 8 // GPRS NET INIT failed
The error code is cleared (red led turned off) once everything is ok.
Regards, Mark.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Hallo everybody I was able to configurate the HomeLinks on both our EU-Roadsters (my wife‘s and mine). We have two garages with two doors. For the opening of the doors we use a german product called maraton 1100SL (the company is Sommer, D- 73230 Kirheim) I did it in two steps: 1. I sent the code from the garage remote control to the Roadster (as described in the Tesla manual „How to configurate HomeLink“) 2. I paired (linked) the HomeLink from the Roadster to the control panel of the garage door (as described in the manual you get with your garage door control pannel) That‘s all. It works good, but the range is a bit shorter than with the original remote control. The frequency of the System is 868Mhz (without external antenna). Piotr Von: ovmsdev-bounces@lists.teslaclub.hk [mailto:ovmsdev-bounces@lists.teslaclub.hk] Im Auftrag von David Morse Gesendet: Samstag, 12. Mai 2012 17:22 An: OVMS Developers Betreff: Re: [Ovmsdev] Car firmware: 1.2.5 Thank you all for working on this. I'm just an end user so can't contribute much more than comments but am looking forward to the cool down feature. I am curious though, does anyone have evidence that the cool down feature in beneficial? If so, I wonder why this is something Tesla never implemented. Thanks. David Sent from my iPad On May 12, 2012, at 9:33 AM, "Oliver Weidmann" <oliver@sdds.ch> wrote: A guy from Switzerland has a working homelink. I’ll have to ask him how he managed to successfully pair it… Von: ovmsdev-bounces@lists.teslaclub.hk [mailto:ovmsdev-bounces@lists.teslaclub.hk] Im Auftrag von Pierre Uhl Gesendet: Samstag, 12. Mai 2012 13:39 An: 'OVMS Developers' Betreff: Re: [Ovmsdev] Car firmware: 1.2.5 Re Homelink The Homelink in Europe is disabled, because the frequency in Europe is not the same like in the US (FCC regulation?). Von: ovmsdev-bounces@lists.teslaclub.hk [mailto:ovmsdev-bounces@lists.teslaclub.hk] Im Auftrag von Mark Webb-Johnson Gesendet: Samstag, 12. Mai 2012 13:22 An: OVMS Developers Betreff: [Ovmsdev] Car firmware: 1.2.5 I've committed to github car firmware v1.2.5. Changes since v1.2.2 include: * Support multiple vehicle configurations - TeslaRoadster and VoltAmpera * New LED indication scheme, and net driver tidy-ups * Auto-support Tesla Roadster v1.5 cars * Issue #38 - Prevent user from locking car if car is ON * Issue #39 - Alert (SMS/PUSH) if trunk is opened while in valet mode Please don't get too excited - this doesn't support Volt/Ampera yet - we're just laying the ground work for that support, as some European developers are about to start work on it. I don't think this release will make it to end-users in its current form. I'm still working on some features to go in, including: 1. Drive logging 2. Charge logging 3. Timed (delayed) charging mode commands 4. Timed charging status feedback 5. Complete-charging-by charging mode 6. Cooldown 7. Moving digital speedo out of experimental and make it available in production units Items [1], [2] and [3] are relatively easy and what I'm working on now. Item [4] is tricky because we haven't found the status update message on the bus yet. Still looking. Item [5] needs the algorithm and lookup table. Item [6] is easy to do, but needs the thresholds defined (what battery temperature to cooldown from, what battery temperature to stop cooldown at, and what current/voltage to use for cooldown). Item [7] seems reasonable now, given the number of cars now using the digital speedo feature and the complete lack of issues seen with it. I notice there was some discussion on the TMC forum about homelink control. That would be pretty easy to do, but we don't have homelink modules here in Hong Kong, and I don't have the can bus codes. They are probably easy to find on ID#102. If someone with a usb-can and a homelink adaptor wants to get the codes, I'm very willing to put them in. It certainly is a cool feature. So, I'm not sure what will make it into what release, when. This v1.2.5 release is definitely developers-only, and intended to check stability of the modem driver revisions and usability of the new LED feedback scheme. It is fully backwards-compatible with v1.2.2, and you can upgrade/downgrade firmware as you need. It is in my car now, and seems to be ok. I would be grateful if developers with some time could try it out and let me have feedback on overall stability and usability of the new LED indication scheme. I've got a little youtube video demonstrating this: http://www.youtube.com/watch?v=MdsB8qK6beY The new LED indication scheme is as follows: 1. When first powered on, the red led stays on, and the green led blinks the version of firmware in the module (e.g.; 1, 2, 5). After that, it enters normal mode. 2. In normal mode, the green led is used to indicate the state, and the red led is used to indicate the last error. 3. If the modem needs to be reset, both red and green leds are turned on for the couple of seconds it takes to reset the modem. The following states are defined: // LED MODES #define NET_LED_WAKEUP 10 // Attempting to wake up the modem #define NET_LED_INITSIM1 9 // Checking SIM card insertion status #define NET_LED_INITSIM2 8 // Checking SIM card PIN status #define NET_LED_INITSIM3 7 // Initialising modem #define NET_LED_COPS 6 // COPS initialisation #define NET_LED_NETINIT 5 // GPRS NET initialisation #define NET_LED_NETAPNOK 4 // GPRS APN is OK, final init #define NET_LED_NETCALL 3 // GPRS Network call #define NET_LED_READY 2 // READY state #define NET_LED_READYGPRS 1 // READY GPRS state The normal behavior is it will start at 10 green blinks and count down to 2 (GSM only) or 1 (GPRS). If GPRS lock is lost, but GSM is still up, the green will blink 1. The followed error codes are defined: // LED ERRORS #define NET_LED_ERRLOSTSIG 1 // Lost signal #define NET_LED_ERRMODEM 2 // Problem communicating with modem #define NET_LED_ERRSIM1 3 // SIM is not inserted/detected #define NET_LED_ERRSIM2 4 // PIN lock on the SIM #define NET_LED_ERRCOPS 6 // COPS GSM lock could not be obtained #define NET_LED_ERRGPRSRETRY 7 // Error (maybe temp) during GPRS init #define NET_LED_ERRGPRSFAIL 8 // GPRS NET INIT failed The error code is cleared (red led turned off) once everything is ok. Regards, Mark. _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
To track down the homelink messages, we'd need someone with both homelink and a way to capture can bus messages (a USB CAN bus tool). I have the tool, but the cars in hong kong have no homelink module installed. The capture itself should be fairly simple. I'd put money on the messages being on ID#102, and there are a very limited number of those messages. Regards, Mark. On 13 May, 2012, at 12:25 AM, 911carrera4 wrote:
Hallo everybody
I was able to configurate the HomeLinks on both our EU-Roadsters (my wife‘s and mine). We have two garages with two doors. For the opening of the doors we use a german product called maraton 1100SL (the company is Sommer, D- 73230 Kirheim)
I did it in two steps: 1. I sent the code from the garage remote control to the Roadster (as described in the Tesla manual „How to configurate HomeLink“) 2. I paired (linked) the HomeLink from the Roadster to the control panel of the garage door (as described in the manual you get with your garage door control pannel)
That‘s all. It works good, but the range is a bit shorter than with the original remote control.
The frequency of the System is 868Mhz (without external antenna).
Piotr
Von: ovmsdev-bounces@lists.teslaclub.hk [mailto:ovmsdev-bounces@lists.teslaclub.hk] Im Auftrag von David Morse Gesendet: Samstag, 12. Mai 2012 17:22 An: OVMS Developers Betreff: Re: [Ovmsdev] Car firmware: 1.2.5
Thank you all for working on this. I'm just an end user so can't contribute much more than comments but am looking forward to the cool down feature. I am curious though, does anyone have evidence that the cool down feature in beneficial? If so, I wonder why this is something Tesla never implemented. Thanks.
David
Sent from my iPad
On May 12, 2012, at 9:33 AM, "Oliver Weidmann" <oliver@sdds.ch> wrote:
A guy from Switzerland has a working homelink. I’ll have to ask him how he managed to successfully pair it…
Von: ovmsdev-bounces@lists.teslaclub.hk [mailto:ovmsdev-bounces@lists.teslaclub.hk] Im Auftrag vonPierre Uhl Gesendet: Samstag, 12. Mai 2012 13:39 An: 'OVMS Developers' Betreff: Re: [Ovmsdev] Car firmware: 1.2.5
Re Homelink
The Homelink in Europe is disabled, because the frequency in Europe is not the same like in the US (FCC regulation?).
Von: ovmsdev-bounces@lists.teslaclub.hk [mailto:ovmsdev-bounces@lists.teslaclub.hk] Im Auftrag vonMark Webb-Johnson Gesendet: Samstag, 12. Mai 2012 13:22 An: OVMS Developers Betreff: [Ovmsdev] Car firmware: 1.2.5
I've committed to github car firmware v1.2.5.
Changes since v1.2.2 include:
Support multiple vehicle configurations - TeslaRoadster and VoltAmpera New LED indication scheme, and net driver tidy-ups Auto-support Tesla Roadster v1.5 cars Issue #38 - Prevent user from locking car if car is ON Issue #39 - Alert (SMS/PUSH) if trunk is opened while in valet mode
Please don't get too excited - this doesn't support Volt/Ampera yet - we're just laying the ground work for that support, as some European developers are about to start work on it.
I don't think this release will make it to end-users in its current form. I'm still working on some features to go in, including:
Drive logging Charge logging Timed (delayed) charging mode commands Timed charging status feedback Complete-charging-by charging mode Cooldown Moving digital speedo out of experimental and make it available in production units
Items [1], [2] and [3] are relatively easy and what I'm working on now.
Item [4] is tricky because we haven't found the status update message on the bus yet. Still looking. Item [5] needs the algorithm and lookup table. Item [6] is easy to do, but needs the thresholds defined (what battery temperature to cooldown from, what battery temperature to stop cooldown at, and what current/voltage to use for cooldown).
Item [7] seems reasonable now, given the number of cars now using the digital speedo feature and the complete lack of issues seen with it.
I notice there was some discussion on the TMC forum about homelink control. That would be pretty easy to do, but we don't have homelink modules here in Hong Kong, and I don't have the can bus codes. They are probably easy to find on ID#102. If someone with a usb-can and a homelink adaptor wants to get the codes, I'm very willing to put them in. It certainly is a cool feature.
So, I'm not sure what will make it into what release, when.
This v1.2.5 release is definitely developers-only, and intended to check stability of the modem driver revisions and usability of the new LED feedback scheme. It is fully backwards-compatible with v1.2.2, and you can upgrade/downgrade firmware as you need.
It is in my car now, and seems to be ok. I would be grateful if developers with some time could try it out and let me have feedback on overall stability and usability of the new LED indication scheme.
I've got a little youtube video demonstrating this:
http://www.youtube.com/watch?v=MdsB8qK6beY
The new LED indication scheme is as follows:
When first powered on, the red led stays on, and the green led blinks the version of firmware in the module (e.g.; 1, 2, 5). After that, it enters normal mode. In normal mode, the green led is used to indicate the state, and the red led is used to indicate the last error. If the modem needs to be reset, both red and green leds are turned on for the couple of seconds it takes to reset the modem.
The following states are defined: // LED MODES #define NET_LED_WAKEUP 10 // Attempting to wake up the modem #define NET_LED_INITSIM1 9 // Checking SIM card insertion status #define NET_LED_INITSIM2 8 // Checking SIM card PIN status #define NET_LED_INITSIM3 7 // Initialising modem #define NET_LED_COPS 6 // COPS initialisation #define NET_LED_NETINIT 5 // GPRS NET initialisation #define NET_LED_NETAPNOK 4 // GPRS APN is OK, final init #define NET_LED_NETCALL 3 // GPRS Network call #define NET_LED_READY 2 // READY state #define NET_LED_READYGPRS 1 // READY GPRS state
The normal behavior is it will start at 10 green blinks and count down to 2 (GSM only) or 1 (GPRS). If GPRS lock is lost, but GSM is still up, the green will blink 1.
The followed error codes are defined: // LED ERRORS #define NET_LED_ERRLOSTSIG 1 // Lost signal #define NET_LED_ERRMODEM 2 // Problem communicating with modem #define NET_LED_ERRSIM1 3 // SIM is not inserted/detected #define NET_LED_ERRSIM2 4 // PIN lock on the SIM #define NET_LED_ERRCOPS 6 // COPS GSM lock could not be obtained #define NET_LED_ERRGPRSRETRY 7 // Error (maybe temp) during GPRS init #define NET_LED_ERRGPRSFAIL 8 // GPRS NET INIT failed
The error code is cleared (red led turned off) once everything is ok.
Regards, Mark.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
I have CAN Hacker on my netbook. I also have a USB-CAN interface. I don't know how much time I'll have in the next week or so. All bets are off, but I'll try to get some work done next week. William On Sat, May 12, 2012 at 9:24 PM, Mark Webb-Johnson <mark@webb-johnson.net>wrote:
To track down the homelink messages, we'd need someone with both homelink and a way to capture can bus messages (a USB CAN bus tool).
I have the tool, but the cars in hong kong have no homelink module installed.
The capture itself should be fairly simple. I'd put money on the messages being on ID#102, and there are a very limited number of those messages.
Regards, Mark.
On 13 May, 2012, at 12:25 AM, 911carrera4 wrote:
Hallo everybody**** ** ** I was able to configurate the HomeLinks on both our EU-Roadsters (my wife‘s and mine). We have two garages with two doors. For the opening of the doors we use a german product called maraton 1100SL (the company is Sommer, D- 73230 Kirheim)**** ** ** I did it in two steps:**** 1. I sent the code from the garage remote control to the Roadster (as described in the Tesla manual „How to configurate HomeLink“)**** 2. I paired (linked) the HomeLink from the Roadster to the control panel of the garage door (as described in the manual you get with your garage door control pannel)**** ** ** That‘s all. It works good, but the range is a bit shorter than with the original remote control.**** ** ** The frequency of the System is 868Mhz (without external antenna).**** ** ** Piotr**** ** ** ** ** *Von:* ovmsdev-bounces@lists.teslaclub.hk [mailto: ovmsdev-bounces@lists.teslaclub.hk] *Im Auftrag von *David Morse *Gesendet:* Samstag, 12. Mai 2012 17:22 *An:* OVMS Developers *Betreff:* Re: [Ovmsdev] Car firmware: 1.2.5**** ** ** Thank you all for working on this. I'm just an end user so can't contribute much more than comments but am looking forward to the cool down feature. I am curious though, does anyone have evidence that the cool down feature in beneficial? If so, I wonder why this is something Tesla never implemented. Thanks. **** ** ** David
Sent from my iPad****
On May 12, 2012, at 9:33 AM, "Oliver Weidmann" <oliver@sdds.ch> wrote:****
A guy from Switzerland has a working homelink. I’ll have to ask him how he managed to successfully pair it…**** **** *Von:* ovmsdev-bounces@lists.teslaclub.hk [mailto:ovmsdev-bounces@lists.teslaclub.hk] *Im Auftrag von*Pierre Uhl *Gesendet:* Samstag, 12. Mai 2012 13:39 *An:* 'OVMS Developers' *Betreff:* Re: [Ovmsdev] Car firmware: 1.2.5**** **** Re Homelink**** **** The Homelink in Europe is disabled, because the frequency in Europe is not the same like in the US (FCC regulation?).**** **** **** *Von:* ovmsdev-bounces@lists.teslaclub.hk [mailto:ovmsdev-bounces@lists.teslaclub.hk] *Im Auftrag von*Mark Webb-Johnson *Gesendet:* Samstag, 12. Mai 2012 13:22 *An:* OVMS Developers *Betreff:* [Ovmsdev] Car firmware: 1.2.5**** **** **** I've committed to github car firmware v1.2.5.**** **** Changes since v1.2.2 include:**** ****
- Support multiple vehicle configurations - TeslaRoadster and VoltAmpera**** - New LED indication scheme, and net driver tidy-ups**** - Auto-support Tesla Roadster v1.5 cars**** - Issue #38 - Prevent user from locking car if car is ON**** - Issue #39 - Alert (SMS/PUSH) if trunk is opened while in valet mode** **
**** Please don't get too excited - this doesn't support Volt/Ampera yet - we're just laying the ground work for that support, as some European developers are about to start work on it.**** **** I don't think this release will make it to end-users in its current form. I'm still working on some features to go in, including:**** ****
1. Drive logging**** 2. Charge logging**** 3. Timed (delayed) charging mode commands**** 4. Timed charging status feedback**** 5. Complete-charging-by charging mode**** 6. Cooldown**** 7. Moving digital speedo out of experimental and make it available in production units****
**** Items [1], [2] and [3] are relatively easy and what I'm working on now.*** * **** Item [4] is tricky because we haven't found the status update message on the bus yet. Still looking. Item [5] needs the algorithm and lookup table. Item [6] is easy to do, but needs the thresholds defined (what battery temperature to cooldown from, what battery temperature to stop cooldown at, and what current/voltage to use for cooldown).**** **** Item [7] seems reasonable now, given the number of cars now using the digital speedo feature and the complete lack of issues seen with it.**** **** I notice there was some discussion on the TMC forum about homelink control. That would be pretty easy to do, but we don't have homelink modules here in Hong Kong, and I don't have the can bus codes. They are probably easy to find on ID#102. If someone with a usb-can and a homelink adaptor wants to get the codes, I'm very willing to put them in. It certainly is a cool feature.**** **** So, I'm not sure what will make it into what release, when.**** **** This v1.2.5 release is definitely developers-only, and intended to check stability of the modem driver revisions and usability of the new LED feedback scheme. It is fully backwards-compatible with v1.2.2, and you can upgrade/downgrade firmware as you need.**** **** It is in my car now, and seems to be ok. I would be grateful if developers with some time could try it out and let me have feedback on overall stability and usability of the new LED indication scheme.**** **** I've got a little youtube video demonstrating this:**** ****
http://www.youtube.com/watch?v=MdsB8qK6beY****
**** The new LED indication scheme is as follows:**** ****
1. When first powered on, the red led stays on, and the green led blinks the version of firmware in the module (e.g.; 1, 2, 5). After that, it enters normal mode.**** 2. In normal mode, the green led is used to indicate the state, and the red led is used to indicate the last error.**** 3. If the modem needs to be reset, both red and green leds are turned on for the couple of seconds it takes to reset the modem.****
**** The following states are defined:****
// LED MODES #define NET_LED_WAKEUP 10 // Attempting to wake up the modem #define NET_LED_INITSIM1 9 // Checking SIM card insertion status #define NET_LED_INITSIM2 8 // Checking SIM card PIN status #define NET_LED_INITSIM3 7 // Initialising modem #define NET_LED_COPS 6 // COPS initialisation #define NET_LED_NETINIT 5 // GPRS NET initialisation #define NET_LED_NETAPNOK 4 // GPRS APN is OK, final init #define NET_LED_NETCALL 3 // GPRS Network call #define NET_LED_READY 2 // READY state #define NET_LED_READYGPRS 1 // READY GPRS state****
**** The normal behavior is it will start at 10 green blinks and count down to 2 (GSM only) or 1 (GPRS). If GPRS lock is lost, but GSM is still up, the green will blink 1.**** **** The followed error codes are defined:****
// LED ERRORS #define NET_LED_ERRLOSTSIG 1 // Lost signal #define NET_LED_ERRMODEM 2 // Problem communicating with modem #define NET_LED_ERRSIM1 3 // SIM is not inserted/detected #define NET_LED_ERRSIM2 4 // PIN lock on the SIM #define NET_LED_ERRCOPS 6 // COPS GSM lock could not be obtained #define NET_LED_ERRGPRSRETRY 7 // Error (maybe temp) during GPRS init #define NET_LED_ERRGPRSFAIL 8 // GPRS NET INIT failed****
**** The error code is cleared (red led turned off) once everything is ok.**** **** Regards, Mark.**** ****
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev****
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
William, If you get a chance, just get a full log dump of that can bus the OVMS uses. Textual is fine (csv, whatever) and a timestamp would be useful. I'm willing to do the analysis, I just need a can dump containing home link transmission messages. Useful if you can key the home link to some other recognizable event. For example, open passenger door, activate home link, close passenger door. We then need only to look at a short part of the log, looking for something new. Car doors are good, but also trunk and hood. Keep clear of charge port because opening that triggers all sorts of other stuff. Also good if you can do it a few times. Whichever, let us know the exact sequence (eg; open left door @15sec in, activate home link 1 about 2 seconds later, then closed left door, did this three times, etc) and how you keyed the event. If you want to look for the event itself, all we know is at: https://raw.github.com/markwj/Open-Vehicle-Monitoring-System/master/vehicle/... A sub-message <B1> on ID#102 is the most likely, as those are messages from the VDS. Regards, Mark On 13 May, 2012, at 12:37 PM, William Petefish <william.petefish@gmail.com> wrote:
I have CAN Hacker on my netbook. I also have a USB-CAN interface. I don't know how much time I'll have in the next week or so. All bets are off, but I'll try to get some work done next week.
William
On Sat, May 12, 2012 at 9:24 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote: To track down the homelink messages, we'd need someone with both homelink and a way to capture can bus messages (a USB CAN bus tool).
I have the tool, but the cars in hong kong have no homelink module installed.
The capture itself should be fairly simple. I'd put money on the messages being on ID#102, and there are a very limited number of those messages.
Regards, Mark.
On 13 May, 2012, at 12:25 AM, 911carrera4 wrote:
Hallo everybody
I was able to configurate the HomeLinks on both our EU-Roadsters (my wife‘s and mine). We have two garages with two doors. For the opening of the doors we use a german product called maraton 1100SL (the company is Sommer, D- 73230 Kirheim)
I did it in two steps: 1. I sent the code from the garage remote control to the Roadster (as described in the Tesla manual „How to configurate HomeLink“) 2. I paired (linked) the HomeLink from the Roadster to the control panel of the garage door (as described in the manual you get with your garage door control pannel)
That‘s all. It works good, but the range is a bit shorter than with the original remote control.
The frequency of the System is 868Mhz (without external antenna).
Piotr
Von: ovmsdev-bounces@lists.teslaclub.hk [mailto:ovmsdev-bounces@lists.teslaclub.hk] Im Auftrag von David Morse Gesendet: Samstag, 12. Mai 2012 17:22 An: OVMS Developers Betreff: Re: [Ovmsdev] Car firmware: 1.2.5
Thank you all for working on this. I'm just an end user so can't contribute much more than comments but am looking forward to the cool down feature. I am curious though, does anyone have evidence that the cool down feature in beneficial? If so, I wonder why this is something Tesla never implemented. Thanks.
David
Sent from my iPad
On May 12, 2012, at 9:33 AM, "Oliver Weidmann" <oliver@sdds.ch> wrote:
A guy from Switzerland has a working homelink. I’ll have to ask him how he managed to successfully pair it…
Von: ovmsdev-bounces@lists.teslaclub.hk [mailto:ovmsdev-bounces@lists.teslaclub.hk] Im Auftrag vonPierre Uhl Gesendet: Samstag, 12. Mai 2012 13:39 An: 'OVMS Developers' Betreff: Re: [Ovmsdev] Car firmware: 1.2.5
Re Homelink
The Homelink in Europe is disabled, because the frequency in Europe is not the same like in the US (FCC regulation?).
Von: ovmsdev-bounces@lists.teslaclub.hk [mailto:ovmsdev-bounces@lists.teslaclub.hk] Im Auftrag vonMark Webb-Johnson Gesendet: Samstag, 12. Mai 2012 13:22 An: OVMS Developers Betreff: [Ovmsdev] Car firmware: 1.2.5
I've committed to github car firmware v1.2.5.
Changes since v1.2.2 include:
Support multiple vehicle configurations - TeslaRoadster and VoltAmpera New LED indication scheme, and net driver tidy-ups Auto-support Tesla Roadster v1.5 cars Issue #38 - Prevent user from locking car if car is ON Issue #39 - Alert (SMS/PUSH) if trunk is opened while in valet mode
Please don't get too excited - this doesn't support Volt/Ampera yet - we're just laying the ground work for that support, as some European developers are about to start work on it.
I don't think this release will make it to end-users in its current form. I'm still working on some features to go in, including:
Drive logging Charge logging Timed (delayed) charging mode commands Timed charging status feedback Complete-charging-by charging mode Cooldown Moving digital speedo out of experimental and make it available in production units
Items [1], [2] and [3] are relatively easy and what I'm working on now.
Item [4] is tricky because we haven't found the status update message on the bus yet. Still looking. Item [5] needs the algorithm and lookup table. Item [6] is easy to do, but needs the thresholds defined (what battery temperature to cooldown from, what battery temperature to stop cooldown at, and what current/voltage to use for cooldown).
Item [7] seems reasonable now, given the number of cars now using the digital speedo feature and the complete lack of issues seen with it.
I notice there was some discussion on the TMC forum about homelink control. That would be pretty easy to do, but we don't have homelink modules here in Hong Kong, and I don't have the can bus codes. They are probably easy to find on ID#102. If someone with a usb-can and a homelink adaptor wants to get the codes, I'm very willing to put them in. It certainly is a cool feature.
So, I'm not sure what will make it into what release, when.
This v1.2.5 release is definitely developers-only, and intended to check stability of the modem driver revisions and usability of the new LED feedback scheme. It is fully backwards-compatible with v1.2.2, and you can upgrade/downgrade firmware as you need.
It is in my car now, and seems to be ok. I would be grateful if developers with some time could try it out and let me have feedback on overall stability and usability of the new LED indication scheme.
I've got a little youtube video demonstrating this:
http://www.youtube.com/watch?v=MdsB8qK6beY
The new LED indication scheme is as follows:
When first powered on, the red led stays on, and the green led blinks the version of firmware in the module (e.g.; 1, 2, 5). After that, it enters normal mode. In normal mode, the green led is used to indicate the state, and the red led is used to indicate the last error. If the modem needs to be reset, both red and green leds are turned on for the couple of seconds it takes to reset the modem.
The following states are defined: // LED MODES #define NET_LED_WAKEUP 10 // Attempting to wake up the modem #define NET_LED_INITSIM1 9 // Checking SIM card insertion status #define NET_LED_INITSIM2 8 // Checking SIM card PIN status #define NET_LED_INITSIM3 7 // Initialising modem #define NET_LED_COPS 6 // COPS initialisation #define NET_LED_NETINIT 5 // GPRS NET initialisation #define NET_LED_NETAPNOK 4 // GPRS APN is OK, final init #define NET_LED_NETCALL 3 // GPRS Network call #define NET_LED_READY 2 // READY state #define NET_LED_READYGPRS 1 // READY GPRS state
The normal behavior is it will start at 10 green blinks and count down to 2 (GSM only) or 1 (GPRS). If GPRS lock is lost, but GSM is still up, the green will blink 1.
The followed error codes are defined: // LED ERRORS #define NET_LED_ERRLOSTSIG 1 // Lost signal #define NET_LED_ERRMODEM 2 // Problem communicating with modem #define NET_LED_ERRSIM1 3 // SIM is not inserted/detected #define NET_LED_ERRSIM2 4 // PIN lock on the SIM #define NET_LED_ERRCOPS 6 // COPS GSM lock could not be obtained #define NET_LED_ERRGPRSRETRY 7 // Error (maybe temp) during GPRS init #define NET_LED_ERRGPRSFAIL 8 // GPRS NET INIT failed
The error code is cleared (red led turned off) once everything is ok.
Regards, Mark.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
I'll do a logging session on monday. I've actually got 2 tools that I can use. (logic analyzer w/ data logging and analyzation functionality, and my CAN-USB which has CAN Hacker which can log and can give individual messages.) William On Sun, May 13, 2012 at 12:14 AM, Mark Webb-Johnson <mark@webb-johnson.net>wrote:
William,
If you get a chance, just get a full log dump of that can bus the OVMS uses. Textual is fine (csv, whatever) and a timestamp would be useful. I'm willing to do the analysis, I just need a can dump containing home link transmission messages.
Useful if you can key the home link to some other recognizable event. For example, open passenger door, activate home link, close passenger door. We then need only to look at a short part of the log, looking for something new. Car doors are good, but also trunk and hood. Keep clear of charge port because opening that triggers all sorts of other stuff. Also good if you can do it a few times. Whichever, let us know the exact sequence (eg; open left door @15sec in, activate home link 1 about 2 seconds later, then closed left door, did this three times, etc) and how you keyed the event.
If you want to look for the event itself, all we know is at:
https://raw.github.com/markwj/Open-Vehicle-Monitoring-System/master/vehicle/...
A sub-message <B1> on ID#102 is the most likely, as those are messages from the VDS.
Regards, Mark
On 13 May, 2012, at 12:37 PM, William Petefish <william.petefish@gmail.com> wrote:
I have CAN Hacker on my netbook. I also have a USB-CAN interface. I don't know how much time I'll have in the next week or so. All bets are off, but I'll try to get some work done next week.
William
On Sat, May 12, 2012 at 9:24 PM, Mark Webb-Johnson <mark@webb-johnson.net>wrote:
To track down the homelink messages, we'd need someone with both homelink and a way to capture can bus messages (a USB CAN bus tool).
I have the tool, but the cars in hong kong have no homelink module installed.
The capture itself should be fairly simple. I'd put money on the messages being on ID#102, and there are a very limited number of those messages.
Regards, Mark.
On 13 May, 2012, at 12:25 AM, 911carrera4 wrote:
Hallo everybody**** ** ** I was able to configurate the HomeLinks on both our EU-Roadsters (my wife‘s and mine). We have two garages with two doors. For the opening of the doors we use a german product called maraton 1100SL (the company is Sommer, D- 73230 Kirheim)**** ** ** I did it in two steps:**** 1. I sent the code from the garage remote control to the Roadster (as described in the Tesla manual „How to configurate HomeLink“)**** 2. I paired (linked) the HomeLink from the Roadster to the control panel of the garage door (as described in the manual you get with your garage door control pannel)**** ** ** That‘s all. It works good, but the range is a bit shorter than with the original remote control.**** ** ** The frequency of the System is 868Mhz (without external antenna).**** ** ** Piotr**** ** ** ** ** *Von:* ovmsdev-bounces@lists.teslaclub.hk [mailto: ovmsdev-bounces@lists.teslaclub.hk] *Im Auftrag von *David Morse *Gesendet:* Samstag, 12. Mai 2012 17:22 *An:* OVMS Developers *Betreff:* Re: [Ovmsdev] Car firmware: 1.2.5**** ** ** Thank you all for working on this. I'm just an end user so can't contribute much more than comments but am looking forward to the cool down feature. I am curious though, does anyone have evidence that the cool down feature in beneficial? If so, I wonder why this is something Tesla never implemented. Thanks. **** ** ** David
Sent from my iPad****
On May 12, 2012, at 9:33 AM, "Oliver Weidmann" <oliver@sdds.ch> wrote:*** *
A guy from Switzerland has a working homelink. I’ll have to ask him how he managed to successfully pair it…**** **** *Von:* ovmsdev-bounces@lists.teslaclub.hk [mailto:ovmsdev-bounces@lists.teslaclub.hk] *Im Auftrag von*Pierre Uhl *Gesendet:* Samstag, 12. Mai 2012 13:39 *An:* 'OVMS Developers' *Betreff:* Re: [Ovmsdev] Car firmware: 1.2.5**** **** Re Homelink**** **** The Homelink in Europe is disabled, because the frequency in Europe is not the same like in the US (FCC regulation?).**** **** **** *Von:* ovmsdev-bounces@lists.teslaclub.hk [mailto:ovmsdev-bounces@lists.teslaclub.hk] *Im Auftrag von*Mark Webb-Johnson *Gesendet:* Samstag, 12. Mai 2012 13:22 *An:* OVMS Developers *Betreff:* [Ovmsdev] Car firmware: 1.2.5**** **** **** I've committed to github car firmware v1.2.5.**** **** Changes since v1.2.2 include:**** ****
- Support multiple vehicle configurations - TeslaRoadster and VoltAmpera**** - New LED indication scheme, and net driver tidy-ups**** - Auto-support Tesla Roadster v1.5 cars**** - Issue #38 - Prevent user from locking car if car is ON**** - Issue #39 - Alert (SMS/PUSH) if trunk is opened while in valet mode* ***
**** Please don't get too excited - this doesn't support Volt/Ampera yet - we're just laying the ground work for that support, as some European developers are about to start work on it.**** **** I don't think this release will make it to end-users in its current form. I'm still working on some features to go in, including:**** ****
1. Drive logging**** 2. Charge logging**** 3. Timed (delayed) charging mode commands**** 4. Timed charging status feedback**** 5. Complete-charging-by charging mode**** 6. Cooldown**** 7. Moving digital speedo out of experimental and make it available in production units****
**** Items [1], [2] and [3] are relatively easy and what I'm working on now.** ** **** Item [4] is tricky because we haven't found the status update message on the bus yet. Still looking. Item [5] needs the algorithm and lookup table. Item [6] is easy to do, but needs the thresholds defined (what battery temperature to cooldown from, what battery temperature to stop cooldown at, and what current/voltage to use for cooldown).**** **** Item [7] seems reasonable now, given the number of cars now using the digital speedo feature and the complete lack of issues seen with it.**** **** I notice there was some discussion on the TMC forum about homelink control. That would be pretty easy to do, but we don't have homelink modules here in Hong Kong, and I don't have the can bus codes. They are probably easy to find on ID#102. If someone with a usb-can and a homelink adaptor wants to get the codes, I'm very willing to put them in. It certainly is a cool feature.**** **** So, I'm not sure what will make it into what release, when.**** **** This v1.2.5 release is definitely developers-only, and intended to check stability of the modem driver revisions and usability of the new LED feedback scheme. It is fully backwards-compatible with v1.2.2, and you can upgrade/downgrade firmware as you need.**** **** It is in my car now, and seems to be ok. I would be grateful if developers with some time could try it out and let me have feedback on overall stability and usability of the new LED indication scheme.**** **** I've got a little youtube video demonstrating this:**** ****
http://www.youtube.com/watch?v=MdsB8qK6beY****
**** The new LED indication scheme is as follows:**** ****
1. When first powered on, the red led stays on, and the green led blinks the version of firmware in the module (e.g.; 1, 2, 5). After that, it enters normal mode.**** 2. In normal mode, the green led is used to indicate the state, and the red led is used to indicate the last error.**** 3. If the modem needs to be reset, both red and green leds are turned on for the couple of seconds it takes to reset the modem.****
**** The following states are defined:****
// LED MODES #define NET_LED_WAKEUP 10 // Attempting to wake up the modem #define NET_LED_INITSIM1 9 // Checking SIM card insertion status #define NET_LED_INITSIM2 8 // Checking SIM card PIN status #define NET_LED_INITSIM3 7 // Initialising modem #define NET_LED_COPS 6 // COPS initialisation #define NET_LED_NETINIT 5 // GPRS NET initialisation #define NET_LED_NETAPNOK 4 // GPRS APN is OK, final init #define NET_LED_NETCALL 3 // GPRS Network call #define NET_LED_READY 2 // READY state #define NET_LED_READYGPRS 1 // READY GPRS state****
**** The normal behavior is it will start at 10 green blinks and count down to 2 (GSM only) or 1 (GPRS). If GPRS lock is lost, but GSM is still up, the green will blink 1.**** **** The followed error codes are defined:****
// LED ERRORS #define NET_LED_ERRLOSTSIG 1 // Lost signal #define NET_LED_ERRMODEM 2 // Problem communicating with modem #define NET_LED_ERRSIM1 3 // SIM is not inserted/detected #define NET_LED_ERRSIM2 4 // PIN lock on the SIM #define NET_LED_ERRCOPS 6 // COPS GSM lock could not be obtained #define NET_LED_ERRGPRSRETRY 7 // Error (maybe temp) during GPRS init #define NET_LED_ERRGPRSFAIL 8 // GPRS NET INIT failed****
**** The error code is cleared (red led turned off) once everything is ok.**** **** Regards, Mark.**** ****
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev****
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
I had trouble with logging. I'll try again in a few days. William On May 13, 2012 1:11 AM, "William Petefish" <william.petefish@gmail.com> wrote:
I'll do a logging session on monday.
I've actually got 2 tools that I can use. (logic analyzer w/ data logging and analyzation functionality, and my CAN-USB which has CAN Hacker which can log and can give individual messages.)
William
On Sun, May 13, 2012 at 12:14 AM, Mark Webb-Johnson <mark@webb-johnson.net
wrote:
William,
If you get a chance, just get a full log dump of that can bus the OVMS uses. Textual is fine (csv, whatever) and a timestamp would be useful. I'm willing to do the analysis, I just need a can dump containing home link transmission messages.
Useful if you can key the home link to some other recognizable event. For example, open passenger door, activate home link, close passenger door. We then need only to look at a short part of the log, looking for something new. Car doors are good, but also trunk and hood. Keep clear of charge port because opening that triggers all sorts of other stuff. Also good if you can do it a few times. Whichever, let us know the exact sequence (eg; open left door @15sec in, activate home link 1 about 2 seconds later, then closed left door, did this three times, etc) and how you keyed the event.
If you want to look for the event itself, all we know is at:
https://raw.github.com/markwj/Open-Vehicle-Monitoring-System/master/vehicle/...
A sub-message <B1> on ID#102 is the most likely, as those are messages from the VDS.
Regards, Mark
On 13 May, 2012, at 12:37 PM, William Petefish < william.petefish@gmail.com> wrote:
I have CAN Hacker on my netbook. I also have a USB-CAN interface. I don't know how much time I'll have in the next week or so. All bets are off, but I'll try to get some work done next week.
William
On Sat, May 12, 2012 at 9:24 PM, Mark Webb-Johnson <mark@webb-johnson.net
wrote:
To track down the homelink messages, we'd need someone with both homelink and a way to capture can bus messages (a USB CAN bus tool).
I have the tool, but the cars in hong kong have no homelink module installed.
The capture itself should be fairly simple. I'd put money on the messages being on ID#102, and there are a very limited number of those messages.
Regards, Mark.
On 13 May, 2012, at 12:25 AM, 911carrera4 wrote:
Hallo everybody**** ** ** I was able to configurate the HomeLinks on both our EU-Roadsters (my wife‘s and mine). We have two garages with two doors. For the opening of the doors we use a german product called maraton 1100SL (the company is Sommer, D- 73230 Kirheim)**** ** ** I did it in two steps:**** 1. I sent the code from the garage remote control to the Roadster (as described in the Tesla manual „How to configurate HomeLink“)**** 2. I paired (linked) the HomeLink from the Roadster to the control panel of the garage door (as described in the manual you get with your garage door control pannel)**** ** ** That‘s all. It works good, but the range is a bit shorter than with the original remote control.**** ** ** The frequency of the System is 868Mhz (without external antenna).**** ** ** Piotr**** ** ** ** ** *Von:* ovmsdev-bounces@lists.teslaclub.hk [mailto: ovmsdev-bounces@lists.teslaclub.hk] *Im Auftrag von *David Morse *Gesendet:* Samstag, 12. Mai 2012 17:22 *An:* OVMS Developers *Betreff:* Re: [Ovmsdev] Car firmware: 1.2.5**** ** ** Thank you all for working on this. I'm just an end user so can't contribute much more than comments but am looking forward to the cool down feature. I am curious though, does anyone have evidence that the cool down feature in beneficial? If so, I wonder why this is something Tesla never implemented. Thanks. **** ** ** David
Sent from my iPad****
On May 12, 2012, at 9:33 AM, "Oliver Weidmann" <oliver@sdds.ch> wrote:** **
A guy from Switzerland has a working homelink. I’ll have to ask him how he managed to successfully pair it…**** **** *Von:* ovmsdev-bounces@lists.teslaclub.hk [mailto:ovmsdev-bounces@lists.teslaclub.hk] *Im Auftrag von*Pierre Uhl *Gesendet:* Samstag, 12. Mai 2012 13:39 *An:* 'OVMS Developers' *Betreff:* Re: [Ovmsdev] Car firmware: 1.2.5**** **** Re Homelink**** **** The Homelink in Europe is disabled, because the frequency in Europe is not the same like in the US (FCC regulation?).**** **** **** *Von:* ovmsdev-bounces@lists.teslaclub.hk [mailto:ovmsdev-bounces@lists.teslaclub.hk] *Im Auftrag von*Mark Webb-Johnson *Gesendet:* Samstag, 12. Mai 2012 13:22 *An:* OVMS Developers *Betreff:* [Ovmsdev] Car firmware: 1.2.5**** **** **** I've committed to github car firmware v1.2.5.**** **** Changes since v1.2.2 include:**** ****
- Support multiple vehicle configurations - TeslaRoadster and VoltAmpera**** - New LED indication scheme, and net driver tidy-ups**** - Auto-support Tesla Roadster v1.5 cars**** - Issue #38 - Prevent user from locking car if car is ON**** - Issue #39 - Alert (SMS/PUSH) if trunk is opened while in valet mode ****
**** Please don't get too excited - this doesn't support Volt/Ampera yet - we're just laying the ground work for that support, as some European developers are about to start work on it.**** **** I don't think this release will make it to end-users in its current form. I'm still working on some features to go in, including:**** ****
1. Drive logging**** 2. Charge logging**** 3. Timed (delayed) charging mode commands**** 4. Timed charging status feedback**** 5. Complete-charging-by charging mode**** 6. Cooldown**** 7. Moving digital speedo out of experimental and make it available in production units****
**** Items [1], [2] and [3] are relatively easy and what I'm working on now.* *** **** Item [4] is tricky because we haven't found the status update message on the bus yet. Still looking. Item [5] needs the algorithm and lookup table. Item [6] is easy to do, but needs the thresholds defined (what battery temperature to cooldown from, what battery temperature to stop cooldown at, and what current/voltage to use for cooldown).**** **** Item [7] seems reasonable now, given the number of cars now using the digital speedo feature and the complete lack of issues seen with it.**** **** I notice there was some discussion on the TMC forum about homelink control. That would be pretty easy to do, but we don't have homelink modules here in Hong Kong, and I don't have the can bus codes. They are probably easy to find on ID#102. If someone with a usb-can and a homelink adaptor wants to get the codes, I'm very willing to put them in. It certainly is a cool feature.**** **** So, I'm not sure what will make it into what release, when.**** **** This v1.2.5 release is definitely developers-only, and intended to check stability of the modem driver revisions and usability of the new LED feedback scheme. It is fully backwards-compatible with v1.2.2, and you can upgrade/downgrade firmware as you need.**** **** It is in my car now, and seems to be ok. I would be grateful if developers with some time could try it out and let me have feedback on overall stability and usability of the new LED indication scheme.**** **** I've got a little youtube video demonstrating this:**** ****
http://www.youtube.com/watch?v=MdsB8qK6beY****
**** The new LED indication scheme is as follows:**** ****
1. When first powered on, the red led stays on, and the green led blinks the version of firmware in the module (e.g.; 1, 2, 5). After that, it enters normal mode.**** 2. In normal mode, the green led is used to indicate the state, and the red led is used to indicate the last error.**** 3. If the modem needs to be reset, both red and green leds are turned on for the couple of seconds it takes to reset the modem.****
**** The following states are defined:****
// LED MODES #define NET_LED_WAKEUP 10 // Attempting to wake up the modem #define NET_LED_INITSIM1 9 // Checking SIM card insertion status #define NET_LED_INITSIM2 8 // Checking SIM card PIN status #define NET_LED_INITSIM3 7 // Initialising modem #define NET_LED_COPS 6 // COPS initialisation #define NET_LED_NETINIT 5 // GPRS NET initialisation #define NET_LED_NETAPNOK 4 // GPRS APN is OK, final init #define NET_LED_NETCALL 3 // GPRS Network call #define NET_LED_READY 2 // READY state #define NET_LED_READYGPRS 1 // READY GPRS state****
**** The normal behavior is it will start at 10 green blinks and count down to 2 (GSM only) or 1 (GPRS). If GPRS lock is lost, but GSM is still up, the green will blink 1.**** **** The followed error codes are defined:****
// LED ERRORS #define NET_LED_ERRLOSTSIG 1 // Lost signal #define NET_LED_ERRMODEM 2 // Problem communicating with modem #define NET_LED_ERRSIM1 3 // SIM is not inserted/detected #define NET_LED_ERRSIM2 4 // PIN lock on the SIM #define NET_LED_ERRCOPS 6 // COPS GSM lock could not be obtained #define NET_LED_ERRGPRSRETRY 7 // Error (maybe temp) during GPRS init #define NET_LED_ERRGPRSFAIL 8 // GPRS NET INIT failed****
**** The error code is cleared (red led turned off) once everything is ok.*** * **** Regards, Mark.**** ****
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev****
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
I also have homelink on my car, and a garage door to test it on, so i'll give it a try asap. Regards, Michael Op 13-5-2012 4:24, Mark Webb-Johnson schreef:
To track down the homelink messages, we'd need someone with both homelink and a way to capture can bus messages (a USB CAN bus tool).
I have the tool, but the cars in hong kong have no homelink module installed.
The capture itself should be fairly simple. I'd put money on the messages being on ID#102, and there are a very limited number of those messages.
Regards, Mark.
On 13 May, 2012, at 12:25 AM, 911carrera4 wrote:
Hallo everybody I was able to configurate the HomeLinks on both our EU-Roadsters (my wife's and mine). We have two garages with two doors. For the opening of the doors we use a german product called maraton 1100SL (the company is Sommer, D- 73230 Kirheim) I did it in two steps: 1.I sent the code from the garage remote control to the Roadster (as described in the Tesla manual "How to configurate HomeLink") 2.I paired (linked) the HomeLink from the Roadster to the control panel of the garage door (as described in the manual you get with your garage door control pannel) That's all. It works good, but the range is a bit shorter than with the original remote control. The frequency of the System is 868Mhz (without external antenna). Piotr *Von:*ovmsdev-bounces@lists.teslaclub.hk <mailto:ovmsdev-bounces@lists.teslaclub.hk>[mailto:ovmsdev-bounces@lists.teslaclub.hk]*Im Auftrag von*David Morse *Gesendet:*Samstag, 12. Mai 2012 17:22 *An:*OVMS Developers *Betreff:*Re: [Ovmsdev] Car firmware: 1.2.5 Thank you all for working on this. I'm just an end user so can't contribute much more than comments but am looking forward to the cool down feature. I am curious though, does anyone have evidence that the cool down feature in beneficial? If so, I wonder why this is something Tesla never implemented. Thanks. David
Sent from my iPad
On May 12, 2012, at 9:33 AM, "Oliver Weidmann" <oliver@sdds.ch <mailto:oliver@sdds.ch>> wrote:
A guy from Switzerland has a working homelink. I'll have to ask him how he managed to successfully pair it... *Von:*ovmsdev-bounces@lists.teslaclub.hk <mailto:ovmsdev-bounces@lists.teslaclub.hk>[mailto:ovmsdev-bounces@lists.teslaclub.hk] <mailto:[mailto:ovmsdev-bounces@lists.teslaclub.hk]>*Im Auftrag von*Pierre Uhl *Gesendet:*Samstag, 12. Mai 2012 13:39 *An:*'OVMS Developers' *Betreff:*Re: [Ovmsdev] Car firmware: 1.2.5 Re Homelink The Homelink in Europe is disabled, because the frequency in Europe is not the same like in the US (FCC regulation?). *Von:*ovmsdev-bounces@lists.teslaclub.hk <mailto:ovmsdev-bounces@lists.teslaclub.hk>[mailto:ovmsdev-bounces@lists.teslaclub.hk] <mailto:[mailto:ovmsdev-bounces@lists.teslaclub.hk]>*Im Auftrag von*Mark Webb-Johnson *Gesendet:*Samstag, 12. Mai 2012 13:22 *An:*OVMS Developers *Betreff:*[Ovmsdev] Car firmware: 1.2.5 I've committed to github car firmware v1.2.5. Changes since v1.2.2 include:
* Support multiple vehicle configurations - TeslaRoadster and VoltAmpera * New LED indication scheme, and net driver tidy-ups * Auto-support Tesla Roadster v1.5 cars * Issue #38 - Prevent user from locking car if car is ON * Issue #39 - Alert (SMS/PUSH) if trunk is opened while in valet mode
Please don't get too excited - this doesn't support Volt/Ampera yet - we're just laying the ground work for that support, as some European developers are about to start work on it. I don't think this release will make it to end-users in its current form. I'm still working on some features to go in, including:
1. Drive logging 2. Charge logging 3. Timed (delayed) charging mode commands 4. Timed charging status feedback 5. Complete-charging-by charging mode 6. Cooldown 7. Moving digital speedo out of experimental and make it available in production units
Items [1], [2] and [3] are relatively easy and what I'm working on now. Item [4] is tricky because we haven't found the status update message on the bus yet. Still looking. Item [5] needs the algorithm and lookup table. Item [6] is easy to do, but needs the thresholds defined (what battery temperature to cooldown from, what battery temperature to stop cooldown at, and what current/voltage to use for cooldown). Item [7] seems reasonable now, given the number of cars now using the digital speedo feature and the complete lack of issues seen with it. I notice there was some discussion on the TMC forum about homelink control. That would be pretty easy to do, but we don't have homelink modules here in Hong Kong, and I don't have the can bus codes. They are probably easy to find on ID#102. If someone with a usb-can and a homelink adaptor wants to get the codes, I'm very willing to put them in. It certainly is a cool feature. So, I'm not sure what will make it into what release, when. This v1.2.5 release is definitely developers-only, and intended to check stability of the modem driver revisions and usability of the new LED feedback scheme. It is fully backwards-compatible with v1.2.2, and you can upgrade/downgrade firmware as you need. It is in my car now, and seems to be ok. I would be grateful if developers with some time could try it out and let me have feedback on overall stability and usability of the new LED indication scheme. I've got a little youtube video demonstrating this:
http://www.youtube.com/watch?v=MdsB8qK6beY
The new LED indication scheme is as follows:
1. When first powered on, the red led stays on, and the green led blinks the version of firmware in the module (e.g.; 1, 2, 5). After that, it enters normal mode. 2. In normal mode, the green led is used to indicate the state, and the red led is used to indicate the last error. 3. If the modem needs to be reset, both red and green leds are turned on for the couple of seconds it takes to reset the modem.
The following states are defined:
// LED MODES #define NET_LED_WAKEUP 10 // Attempting to wake up the modem #define NET_LED_INITSIM1 9 // Checking SIM card insertion status #define NET_LED_INITSIM2 8 // Checking SIM card PIN status #define NET_LED_INITSIM3 7 // Initialising modem #define NET_LED_COPS 6 // COPS initialisation #define NET_LED_NETINIT 5 // GPRS NET initialisation #define NET_LED_NETAPNOK 4 // GPRS APN is OK, final init #define NET_LED_NETCALL 3 // GPRS Network call #define NET_LED_READY 2 // READY state #define NET_LED_READYGPRS 1 // READY GPRS state
The normal behavior is it will start at 10 green blinks and count down to 2 (GSM only) or 1 (GPRS). If GPRS lock is lost, but GSM is still up, the green will blink 1. The followed error codes are defined:
// LED ERRORS #define NET_LED_ERRLOSTSIG 1 // Lost signal #define NET_LED_ERRMODEM 2 // Problem communicating with modem #define NET_LED_ERRSIM1 3 // SIM is not inserted/detected #define NET_LED_ERRSIM2 4 // PIN lock on the SIM #define NET_LED_ERRCOPS 6 // COPS GSM lock could not be obtained #define NET_LED_ERRGPRSRETRY 7 // Error (maybe temp) during GPRS init #define NET_LED_ERRGPRSFAIL 8 // GPRS NET INIT failed
The error code is cleared (red led turned off) once everything is ok. Regards, Mark.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Stegen Electronics Kwartslaan 95 3162 RD Rhoon The Netherlands Tel: +31 10-5016960 www.stegen.com
Homelink is on ID #102 as expected, Sub ID is 0x09 B1= 0x09 B2= 0x00 B3= 0x00 (for first Homelink device, 0x01 for second) There is also another message on the Can bus just before this message, it's 0x09 0x02 0x00, not sure if it's important. I tried sending 0x09 0x00 0x00 back, and it opened/closed my garage door. sending 0x09 0x02 0x00 did not do anything. -Michael Op 15-5-2012 21:35, Michael Stegen schreef:
I also have homelink on my car, and a garage door to test it on, so i'll give it a try asap.
Regards, Michael
Op 13-5-2012 4:24, Mark Webb-Johnson schreef:
To track down the homelink messages, we'd need someone with both homelink and a way to capture can bus messages (a USB CAN bus tool).
I have the tool, but the cars in hong kong have no homelink module installed.
The capture itself should be fairly simple. I'd put money on the messages being on ID#102, and there are a very limited number of those messages.
Regards, Mark.
On 13 May, 2012, at 12:25 AM, 911carrera4 wrote:
Hallo everybody I was able to configurate the HomeLinks on both our EU-Roadsters (my wife's and mine). We have two garages with two doors. For the opening of the doors we use a german product called maraton 1100SL (the company is Sommer, D- 73230 Kirheim) I did it in two steps: 1.I sent the code from the garage remote control to the Roadster (as described in the Tesla manual "How to configurate HomeLink") 2.I paired (linked) the HomeLink from the Roadster to the control panel of the garage door (as described in the manual you get with your garage door control pannel) That's all. It works good, but the range is a bit shorter than with the original remote control. The frequency of the System is 868Mhz (without external antenna). Piotr *Von:*ovmsdev-bounces@lists.teslaclub.hk <mailto:ovmsdev-bounces@lists.teslaclub.hk>[mailto:ovmsdev-bounces@lists.teslaclub.hk]*Im Auftrag von*David Morse *Gesendet:*Samstag, 12. Mai 2012 17:22 *An:*OVMS Developers *Betreff:*Re: [Ovmsdev] Car firmware: 1.2.5 Thank you all for working on this. I'm just an end user so can't contribute much more than comments but am looking forward to the cool down feature. I am curious though, does anyone have evidence that the cool down feature in beneficial? If so, I wonder why this is something Tesla never implemented. Thanks. David
Sent from my iPad
On May 12, 2012, at 9:33 AM, "Oliver Weidmann" <oliver@sdds.ch <mailto:oliver@sdds.ch>> wrote:
A guy from Switzerland has a working homelink. I'll have to ask him how he managed to successfully pair it... *Von:*ovmsdev-bounces@lists.teslaclub.hk <mailto:ovmsdev-bounces@lists.teslaclub.hk>[mailto:ovmsdev-bounces@lists.teslaclub.hk] <mailto:[mailto:ovmsdev-bounces@lists.teslaclub.hk]>*Im Auftrag von*Pierre Uhl *Gesendet:*Samstag, 12. Mai 2012 13:39 *An:*'OVMS Developers' *Betreff:*Re: [Ovmsdev] Car firmware: 1.2.5 Re Homelink The Homelink in Europe is disabled, because the frequency in Europe is not the same like in the US (FCC regulation?). *Von:*ovmsdev-bounces@lists.teslaclub.hk <mailto:ovmsdev-bounces@lists.teslaclub.hk>[mailto:ovmsdev-bounces@lists.teslaclub.hk] <mailto:[mailto:ovmsdev-bounces@lists.teslaclub.hk]>*Im Auftrag von*Mark Webb-Johnson *Gesendet:*Samstag, 12. Mai 2012 13:22 *An:*OVMS Developers *Betreff:*[Ovmsdev] Car firmware: 1.2.5 I've committed to github car firmware v1.2.5. Changes since v1.2.2 include:
* Support multiple vehicle configurations - TeslaRoadster and VoltAmpera * New LED indication scheme, and net driver tidy-ups * Auto-support Tesla Roadster v1.5 cars * Issue #38 - Prevent user from locking car if car is ON * Issue #39 - Alert (SMS/PUSH) if trunk is opened while in valet mode
Please don't get too excited - this doesn't support Volt/Ampera yet - we're just laying the ground work for that support, as some European developers are about to start work on it. I don't think this release will make it to end-users in its current form. I'm still working on some features to go in, including:
1. Drive logging 2. Charge logging 3. Timed (delayed) charging mode commands 4. Timed charging status feedback 5. Complete-charging-by charging mode 6. Cooldown 7. Moving digital speedo out of experimental and make it available in production units
Items [1], [2] and [3] are relatively easy and what I'm working on now. Item [4] is tricky because we haven't found the status update message on the bus yet. Still looking. Item [5] needs the algorithm and lookup table. Item [6] is easy to do, but needs the thresholds defined (what battery temperature to cooldown from, what battery temperature to stop cooldown at, and what current/voltage to use for cooldown). Item [7] seems reasonable now, given the number of cars now using the digital speedo feature and the complete lack of issues seen with it. I notice there was some discussion on the TMC forum about homelink control. That would be pretty easy to do, but we don't have homelink modules here in Hong Kong, and I don't have the can bus codes. They are probably easy to find on ID#102. If someone with a usb-can and a homelink adaptor wants to get the codes, I'm very willing to put them in. It certainly is a cool feature. So, I'm not sure what will make it into what release, when. This v1.2.5 release is definitely developers-only, and intended to check stability of the modem driver revisions and usability of the new LED feedback scheme. It is fully backwards-compatible with v1.2.2, and you can upgrade/downgrade firmware as you need. It is in my car now, and seems to be ok. I would be grateful if developers with some time could try it out and let me have feedback on overall stability and usability of the new LED indication scheme. I've got a little youtube video demonstrating this:
http://www.youtube.com/watch?v=MdsB8qK6beY
The new LED indication scheme is as follows:
1. When first powered on, the red led stays on, and the green led blinks the version of firmware in the module (e.g.; 1, 2, 5). After that, it enters normal mode. 2. In normal mode, the green led is used to indicate the state, and the red led is used to indicate the last error. 3. If the modem needs to be reset, both red and green leds are turned on for the couple of seconds it takes to reset the modem.
The following states are defined:
// LED MODES #define NET_LED_WAKEUP 10 // Attempting to wake up the modem #define NET_LED_INITSIM1 9 // Checking SIM card insertion status #define NET_LED_INITSIM2 8 // Checking SIM card PIN status #define NET_LED_INITSIM3 7 // Initialising modem #define NET_LED_COPS 6 // COPS initialisation #define NET_LED_NETINIT 5 // GPRS NET initialisation #define NET_LED_NETAPNOK 4 // GPRS APN is OK, final init #define NET_LED_NETCALL 3 // GPRS Network call #define NET_LED_READY 2 // READY state #define NET_LED_READYGPRS 1 // READY GPRS state
The normal behavior is it will start at 10 green blinks and count down to 2 (GSM only) or 1 (GPRS). If GPRS lock is lost, but GSM is still up, the green will blink 1. The followed error codes are defined:
// LED ERRORS #define NET_LED_ERRLOSTSIG 1 // Lost signal #define NET_LED_ERRMODEM 2 // Problem communicating with modem #define NET_LED_ERRSIM1 3 // SIM is not inserted/detected #define NET_LED_ERRSIM2 4 // PIN lock on the SIM #define NET_LED_ERRCOPS 6 // COPS GSM lock could not be obtained #define NET_LED_ERRGPRSRETRY 7 // Error (maybe temp) during GPRS init #define NET_LED_ERRGPRSFAIL 8 // GPRS NET INIT failed
The error code is cleared (red led turned off) once everything is ok. Regards, Mark.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Stegen Electronics Kwartslaan 95 3162 RD Rhoon The Netherlands
Tel: +31 10-5016960 www.stegen.com
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Stegen Electronics Kwartslaan 95 3162 RD Rhoon The Netherlands Tel: +31 10-5016960 www.stegen.com
Michael, I like easy ones ;-) Is message length 3 bytes? Also, there are 3 possible home link devices, right? Could the 0x02 message be a wake up (something like the ID#102 B1=0x0a message)? Can you send me a CSV log to use to replay for testing? Thanks, Mark On 16 May, 2012, at 6:16 PM, Michael Stegen wrote:
Homelink is on ID #102 as expected, Sub ID is 0x09
B1= 0x09 B2= 0x00 B3= 0x00 (for first Homelink device, 0x01 for second)
There is also another message on the Can bus just before this message, it's 0x09 0x02 0x00, not sure if it's important.
I tried sending 0x09 0x00 0x00 back, and it opened/closed my garage door. sending 0x09 0x02 0x00 did not do anything.
-Michael
Op 15-5-2012 21:35, Michael Stegen schreef:
I also have homelink on my car, and a garage door to test it on, so i'll give it a try asap.
Regards, Michael
Op 13-5-2012 4:24, Mark Webb-Johnson schreef:
To track down the homelink messages, we'd need someone with both homelink and a way to capture can bus messages (a USB CAN bus tool).
I have the tool, but the cars in hong kong have no homelink module installed.
The capture itself should be fairly simple. I'd put money on the messages being on ID#102, and there are a very limited number of those messages.
Regards, Mark.
On 13 May, 2012, at 12:25 AM, 911carrera4 wrote:
Hallo everybody
I was able to configurate the HomeLinks on both our EU-Roadsters (my wife‘s and mine). We have two garages with two doors. For the opening of the doors we use a german product called maraton 1100SL (the company is Sommer, D- 73230 Kirheim)
I did it in two steps: 1. I sent the code from the garage remote control to the Roadster (as described in the Tesla manual „How to configurate HomeLink“) 2. I paired (linked) the HomeLink from the Roadster to the control panel of the garage door (as described in the manual you get with your garage door control pannel)
That‘s all. It works good, but the range is a bit shorter than with the original remote control.
The frequency of the System is 868Mhz (without external antenna).
Piotr
Von: ovmsdev-bounces@lists.teslaclub.hk [mailto:ovmsdev-bounces@lists.teslaclub.hk] Im Auftrag von David Morse Gesendet: Samstag, 12. Mai 2012 17:22 An: OVMS Developers Betreff: Re: [Ovmsdev] Car firmware: 1.2.5
Thank you all for working on this. I'm just an end user so can't contribute much more than comments but am looking forward to the cool down feature. I am curious though, does anyone have evidence that the cool down feature in beneficial? If so, I wonder why this is something Tesla never implemented. Thanks.
David
Sent from my iPad
On May 12, 2012, at 9:33 AM, "Oliver Weidmann" <oliver@sdds.ch> wrote:
A guy from Switzerland has a working homelink. I’ll have to ask him how he managed to successfully pair it…
Von: ovmsdev-bounces@lists.teslaclub.hk [mailto:ovmsdev-bounces@lists.teslaclub.hk] Im Auftrag vonPierre Uhl Gesendet: Samstag, 12. Mai 2012 13:39 An: 'OVMS Developers' Betreff: Re: [Ovmsdev] Car firmware: 1.2.5
Re Homelink
The Homelink in Europe is disabled, because the frequency in Europe is not the same like in the US (FCC regulation?).
Von: ovmsdev-bounces@lists.teslaclub.hk [mailto:ovmsdev-bounces@lists.teslaclub.hk] Im Auftrag vonMark Webb-Johnson Gesendet: Samstag, 12. Mai 2012 13:22 An: OVMS Developers Betreff: [Ovmsdev] Car firmware: 1.2.5
I've committed to github car firmware v1.2.5.
Changes since v1.2.2 include:
Support multiple vehicle configurations - TeslaRoadster and VoltAmpera New LED indication scheme, and net driver tidy-ups Auto-support Tesla Roadster v1.5 cars Issue #38 - Prevent user from locking car if car is ON Issue #39 - Alert (SMS/PUSH) if trunk is opened while in valet mode
Please don't get too excited - this doesn't support Volt/Ampera yet - we're just laying the ground work for that support, as some European developers are about to start work on it.
I don't think this release will make it to end-users in its current form. I'm still working on some features to go in, including:
Drive logging Charge logging Timed (delayed) charging mode commands Timed charging status feedback Complete-charging-by charging mode Cooldown Moving digital speedo out of experimental and make it available in production units
Items [1], [2] and [3] are relatively easy and what I'm working on now.
Item [4] is tricky because we haven't found the status update message on the bus yet. Still looking. Item [5] needs the algorithm and lookup table. Item [6] is easy to do, but needs the thresholds defined (what battery temperature to cooldown from, what battery temperature to stop cooldown at, and what current/voltage to use for cooldown).
Item [7] seems reasonable now, given the number of cars now using the digital speedo feature and the complete lack of issues seen with it.
I notice there was some discussion on the TMC forum about homelink control. That would be pretty easy to do, but we don't have homelink modules here in Hong Kong, and I don't have the can bus codes. They are probably easy to find on ID#102. If someone with a usb-can and a homelink adaptor wants to get the codes, I'm very willing to put them in. It certainly is a cool feature.
So, I'm not sure what will make it into what release, when.
This v1.2.5 release is definitely developers-only, and intended to check stability of the modem driver revisions and usability of the new LED feedback scheme. It is fully backwards-compatible with v1.2.2, and you can upgrade/downgrade firmware as you need.
It is in my car now, and seems to be ok. I would be grateful if developers with some time could try it out and let me have feedback on overall stability and usability of the new LED indication scheme.
I've got a little youtube video demonstrating this:
http://www.youtube.com/watch?v=MdsB8qK6beY
The new LED indication scheme is as follows:
When first powered on, the red led stays on, and the green led blinks the version of firmware in the module (e.g.; 1, 2, 5). After that, it enters normal mode. In normal mode, the green led is used to indicate the state, and the red led is used to indicate the last error. If the modem needs to be reset, both red and green leds are turned on for the couple of seconds it takes to reset the modem.
The following states are defined: // LED MODES #define NET_LED_WAKEUP 10 // Attempting to wake up the modem #define NET_LED_INITSIM1 9 // Checking SIM card insertion status #define NET_LED_INITSIM2 8 // Checking SIM card PIN status #define NET_LED_INITSIM3 7 // Initialising modem #define NET_LED_COPS 6 // COPS initialisation #define NET_LED_NETINIT 5 // GPRS NET initialisation #define NET_LED_NETAPNOK 4 // GPRS APN is OK, final init #define NET_LED_NETCALL 3 // GPRS Network call #define NET_LED_READY 2 // READY state #define NET_LED_READYGPRS 1 // READY GPRS state
The normal behavior is it will start at 10 green blinks and count down to 2 (GSM only) or 1 (GPRS). If GPRS lock is lost, but GSM is still up, the green will blink 1.
The followed error codes are defined: // LED ERRORS #define NET_LED_ERRLOSTSIG 1 // Lost signal #define NET_LED_ERRMODEM 2 // Problem communicating with modem #define NET_LED_ERRSIM1 3 // SIM is not inserted/detected #define NET_LED_ERRSIM2 4 // PIN lock on the SIM #define NET_LED_ERRCOPS 6 // COPS GSM lock could not be obtained #define NET_LED_ERRGPRSRETRY 7 // Error (maybe temp) during GPRS init #define NET_LED_ERRGPRSFAIL 8 // GPRS NET INIT failed
The error code is cleared (red led turned off) once everything is ok.
Regards, Mark.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Stegen Electronics Kwartslaan 95 3162 RD Rhoon The Netherlands
Tel: +31 10-5016960 www.stegen.com
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Stegen Electronics Kwartslaan 95 3162 RD Rhoon The Netherlands
Tel: +31 10-5016960 www.stegen.com <Homelink_open_close.csv>_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
on 5/12/12 8:22 AM, David Morse wrote:
I am curious though, does anyone have evidence that the cool down feature in beneficial? If so, I wonder why this is something Tesla never implemented.
Tesla recommends that you plug in the car whenever you can and especially if the battery is hot. This is problematic if your electricity is billed on time-of-use, or you want to do your charging off-peak for some other reason. So for days when you arrive home with a hot battery during the day and want to be nice to the battery, but also want to limit your use of power during peak demand hours, a cooldown feature is highly desirable. I installed a Tesla Tatter last summer and used the cooldown feature a lot, it's very nice. It is an open question as to how beneficial it is to battery longevity. Drawing lots of current from a hot battery is definitely bad for battery health; that's been proven by several Roadster owners. It's less clear if letting a battery pack sit hot while drawing little or no current is a problem. To delay a $40,000 battery replacement, I'm happy to err on the side of caution. In August of 2009, I asked Tesla to implement a cooldown feature and was told: "The idea of allowing you to cool the pack while only pulling enough energy from the wall to do so is something that we've talked about. Unfortunately, although the idea is simple, there are some significant hurdles in implementing." That didn't stop Scott451 from doing it, with no help from Tesla. Now Scott works for Tesla. Tom
participants (7)
-
911carrera4 -
David Morse -
Mark Webb-Johnson -
Michael Stegen -
Oliver Weidmann -
Tom Saxton -
William Petefish