[Ovmsdev] Car firmware: 1.2.5

Michael Stegen michael at stegen.com
Wed May 16 18:16:02 HKT 2012


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 at lists.teslaclub.hk 
>>> <mailto:ovmsdev-bounces at lists.teslaclub.hk>[mailto:ovmsdev-bounces at 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 at sdds.ch 
>>> <mailto:oliver at 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 at lists.teslaclub.hk
>>>     <mailto:ovmsdev-bounces at lists.teslaclub.hk>[mailto:ovmsdev-bounces at lists.teslaclub.hk]
>>>     <mailto:[mailto:ovmsdev-bounces at 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 at lists.teslaclub.hk
>>>     <mailto:ovmsdev-bounces at lists.teslaclub.hk>[mailto:ovmsdev-bounces at lists.teslaclub.hk]
>>>     <mailto:[mailto:ovmsdev-bounces at 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 at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>>>     http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>
>>
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at 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 at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20120516/288fa88f/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Homelink_open_close.csv
Type: application/vnd.ms-excel
Size: 1562 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20120516/288fa88f/attachment-0002.xlb>


More information about the OvmsDev mailing list