For the polling framework, there are states. The idea is that different items can be polled at different frequencies (or not at all) in different states. For the leaf, I suggest two states - car on and car off. Then move the polling to car on state. That should stop the relay clicking. You switch states based on passive monitoring of the can bus. Regard, Mark
On 8 May 2016, at 4:32 PM, Michael Balzer <dexter@expeedo.de> wrote:
Am 08.05.2016 um 01:19 schrieb Tom Parker:
On 05/04/2016 11:14 PM, Michael Balzer wrote: there is no climate control command set yet, you can introduce one. Try to define it as common as possible, so it can be used for other vehicles as well.
Should there be one command to turn on climate control and another to turn it off, or one command with a parameter for on or off?
Rule of thumb: use different API (MSG) commands if you need to be able to control separate subsystems/functions independent of each other and/or from different clients.
As there normally should be one client controlling all climate parameters (the App), I think all parameters can be set using one command.
For text commands, different command names may be appropriate for better usability. For example "UNLOCK" is better than "LOCK OFF". But for a climate control text command, you can certainly better use something like "CLIMATE OFF" than "CLIMATEOFF".
Make a proposition.
If you add the command set to the framework instead of the Leaf module, take care to also add a compiler option, as ROM space is very tight on the Twizy.
The "command" I've added is just a #define in net_msg.h. There's no state or logic involved -- when you receive the command, wake up the car and send the appropriate CAN frame. If the car is already awake, it ignores the wakeup and message. So I don't think adding it to the framework is needed?
Having said that, the Nissan implementation of the feature sends the command can frame repeatedly for a while, and a "send this message at this frequency for this time" seems like something other cars might use?
If you add to another module than vehicle_nissanleaf, you technically add to the framework. But a climate control command set does not need to be in the framework code. For example, there is the LOCK and VALET mode command set, that's just defined as common functionality, but only implemented by cars that are capable of this. See the teslaroadster and twizy modules for command dispatcher extensions.
Regarding periodic frames with defined frequency, there's support for this in the OBD polling system already. You can define three separate frequencies for three states in the polling table, states can be set using the polling API. If that's not enough, you can also switch polling tables. Maybe you can use that? -- or extend if necessary.
Regards, Michael
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
<dexter.vcf> _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev