[Ovmsdev] Added Pushover and SSL client support
Michael Balzer
dexter at expeedo.de
Tue Oct 22 04:39:08 HKT 2019
PS: I've got an open fix to a ressource leak in pushover.cpp, if you've been working on it, you can better integrate that as well:
In SendMessageOpt(), the http and post ostringstreams won't get deleted in the error branches.
Regards,
Michael
Am 21.10.19 um 22:34 schrieb Michael Balzer:
> 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
>
> _______________________________________________
> 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/49b8d186/attachment.htm>
More information about the OvmsDev
mailing list