[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