[Ovmsdev] Added Pushover and SSL client support
Michael Balzer
dexter at expeedo.de
Tue Oct 22 04:34:20 HKT 2019
Marko,
it's about saving RAM and CPU load, saving boot time and keeping the processing queues as small as possible for the user configuration. There should be no
running tasks or registered listeners if a service isn't activated, and buffers shouldn't be preallocated etc.. Basically just the component resting in ROM,
waiting for activation by the user.
But you're right, if the service has no permanent connection and doesn't have a task or complex state, the explicit start/stop scheme isn't strictly necessary
and can be done implicitly by listening to the config.
Just take care to only register your notify reader once and reuse the reader id on later reactivation. Reason: the notify registry has no reusing mechanism but
always allocates the next bit for a new reader (and bits are limited).
As a side note: if it's simply a https client wrapper, maybe the manual send command shouldn't need an activated service at all?
Regards,
Michael
Am 21.10.19 um 21:51 schrieb Marko Juhanne:
> Hi Michael,
>
> I've now made changes it so that sending notifications is retried when connectivity is restored, and also made the filtering smarter so that no unnecessary
> messages are retained.
>
> Before continuing with this service start/stop feature, just wanted to make sure what is it we are trying to accomplish. Is this to save memory and/or CPU
> cycles? I mean, there is no persistent connection to the Pushover service, but every notification/message is sent with a separate connection. And there's also
> the "enable pushover service" config to disable forwarding the notifications to Pushover service. I could make it even faster/efficient via deregistering the
> reader/event handler when the service is disabled.
>
> But I'm slightly tilted against to changing the Pushover class to mimic OvmsServer (e.g. starting/stopping the server by creating a separate instance), since
> then sending test messages by console or web UI we need facilities to check if server is running, and starting and stopping it on demand via web UI and
> console etc.. IMHO this adds unnecessary complexity, since Pushover class is basically just a https client wrapper with a notification/event handler, the
> latter which can be disabled easily.
> But please correct me if I've overlooked something or if you had something else in mind.
>
> Best regards,
> Marko
>
>
>
> On Sat, Oct 19, 2019 at 1:41 PM Michael Balzer <dexter at expeedo.de <mailto:dexter at expeedo.de>> wrote:
>
> …or alternatively / additional to the pcp scheme implement "start" & "stop" commands as shown by the v2/v3 servers.
>
>
> Am 19.10.19 um 12:38 schrieb Michael Balzer:
>> Marko,
>>
>> I guess you already saw my quick fix to the pushover module. Failing to clear the "read" flag leads to messages being held indefinitely by the
>> notification system.
>>
>> The fix is no real solution, as the current implementation will drop messages being raised during a network outage. A notify reader may use the "read"
>> flag to keep the messages on temporary loss of connectivity, but it needs to retry sending itself. There is no automatic re-delivery of messages. So you
>> need to add some flag telling the component to check for undelivered messages, as is shown in the server v2 / v3 code.
>>
>> Also, as you're able to tell by your nice filter mechanism if a notification should be sent to the pushover service, you should check that filter already
>> in the filter callback. By doing so, messages without actual readers won't be queued in the first place, so that saves processing time and RAM.
>>
>> I was also surprised by the service running without activation. The standard scheme for optional components is to implement the "pcp" power control
>> scheme and add an AutoInit() integration.
>>
>> Regards,
>> Michael
>>
>>
>> Am 18.10.19 um 15:25 schrieb Michael Balzer:
>>> The Pushover support isn't enabled now in our default builds, because…
>>>
>>> a) MBEDTLS_PSK_MODES defaults to "no"
>>> b) MG_ENABLE_SSL also defaults to "no"
>>> c) OVMS_COMP_PUSHOVER would default to "yes" but depends on a) + b)
>>>
>>> Should we set these to "yes" for the edge release now?
>>>
>>> Regards,
>>> Michael
>>>
>>>
>>> Am 29.07.19 um 21:07 schrieb Marko Juhanne:
>>>> Hello all,
>>>>
>>>> I've been wanting to have a bit more configurable notification system on my mobile phone compared to the OVMS mobile app (quiet hours, different
>>>> message priority levels, override quiet hours with emergency priority, custom sounds, persistent notifications demanding acknowledgment etc). I
>>>> already use Pushover as notification platform for my home automation system and it has worked nicely for these two past years so I decided to port
>>>> Pushover client to OVMS as well.
>>>>
>>>> For those who don't know, Pushover is a notification platform that has apps for iOS and Android. They also have a desktop (actually web) application as
>>>> well. You create an account and then register your application. There's a 5 USD per platform one-time fee, which I find quite reasonable. Message limit
>>>> is 7500 messages / month / application. So if you have multiple cars, you could register them as individual applications. I'm not affiliated with the
>>>> company, just a happy customer.
>>>>
>>>> There are now commits for Pushover support on my fork (https://github.com/mjuhanne/Open-Vehicle-Monitoring-System-3). It's up to date with the main
>>>> branch, and has the SWCAN commits as well. I would appreciate if others could test it before making a pull request, since there are now quite many
>>>> changes. I didn't want to add another http client, so I used Mongoose. But then after enabling SSL support using mbedssl I found out that there's this
>>>> client space "struct mg_connect_opts" that will be too small (and causes crash) if MG_ENABLE_SSL is not enabled also in every component that uses
>>>> Mongoose.
>>>>
>>>> To configure Pushover, there's a new Config/Notifications page on OVMS. You can filter which notifications and events will be relayed and select their
>>>> priority levels accordingly. I thought about using web config pluging, but maybe we could integrate this page to configure notifications for OVMS
>>>> mobile apps as well?
>>>>
>>>> Best regards,
>>>> Marko Juhanne
>>>>
>>>>
>>>> _______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>
>>> --
>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>>
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>
>> --
>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
> --
> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20191021/46857eba/attachment.htm>
More information about the OvmsDev
mailing list