HS3 Pushover Plugin

[bsobel]

Hi,

I have a few small requests I hope you can consider making in your plugin. I posted a long article in the developer forum on some best practices after working on HS internals bug for quite some time. That has given me a good look into the performance of many plugins now that multithreading is working as intended, as before all of your plugin threads were actually having their API calls performed in sequential order do to the RPC remoting processing call on a single thread on both sides of the RPC connection.

There are two performance issues I would like you to know about and ideally address:

Each HS call entails creating a request message, sending it to the server, processing it, and returning its results. As such, any reduction in call count helps overall system performance. In the current plugin you call GetOSType() quite a few times as well as GetAppPath() almost the same. I think you are building a path to call to get an ini setting. Can you kindly save the results of those two calls and reuse them, their values will not change at runtime.

Best
Bill

[mrhappy]

Each HS call entails creating a request message, sending it to the server, processing it, and returning its results. As such, any reduction in call count helps overall system performance. In the current plugin you call GetOSType() quite a few times as well as GetAppPath() almost the same. I think you are building a path to call to get an ini setting. Can you kindly save the results of those two calls and reuse them, their values will not change at runtime.

Fair point, they both are in the same function (a logging function, determine the OS type to determine the path structure and then get the HS path to determine where put the log files) so can be changed and in hindsight I think I put them there in a rush as I can see they are going to be called constantly.

On my system, with threading fixed, you have a thread I think in a loop somewhere. It is taking up 100% cpu time on one core on my system. This is likely due to the fact that the thread was unintentionally limited prior due to the RPC sequential nature which acted as a natural delay (the system is running MUCH faster now in general). I can confirm that when this is happening you are NOT calling HS api's (so my window into what you are doing is limited). But its probably one of your worker threads spinning in a loop that probably needs a sleep or wait (depending on what would entail that thread having more work to do). Can you take a peek and see if you can find the culprit, I am happy to test a fix here as you may not see the behavior yourself until Rich released an update with the RPC fixes that were made.

There is only one thread in the plugin so that narrows it down somewhat. Most of the code inside that thread is not particularly contentious apart from me running through the enumerator and registering a web page. It registers the web page first then runs, does a bit more like sets up some timers and then through the enumerator to determine whether or not the plugin has devices. I've seen your other posts and from what I can understand I think I will need to check those calls are appropriately safeguarded.

It may be that I can get rid of the enumerator alltogether and like others I am a bit mystified that it takes as long as it takes. I was always a bit surprised that a simple call of something like hs.getplugindevices (where you pass in a plugin name and instance) was not written instead, I remember that in the HS3 developer webinar there was some discussion over the enumerator and I think it was originally not part of the HS3 spec and only added after some protest.

[DJF3]

My fault my IP was incorrect on my Dynamic DNS - should be back up now.

Looks like it's down again
(maybe not but the site is getting blocked by Umbrella: Block Reason: DNS RPZ)

Do you have a new URL?

[mrhappy]

Of Course.
here is the event in full.

and here is the CurrentImage.jpg

I'd have to check whether or not the testing was ever done to send images on Linux. I think I checked it but who knows if there has been changes to Mono in the intervening period, having looked at the code and from memory this was a surprisingly difficult thing to get working correctly as the file had to be read as bytes and encoded into the HTTP form. I don't know how well Linux/Mono behaves whilst doing this and as it is passing through the various checks I put in (file size, file type, file exists etc) then it must be getting to the point it thinkgs that it can deal with the file.

[ez1976]

Of Course.
here is the event in full.

and here is the CurrentImage.jpg

[mrhappy]

Hi
i moved my homeseer from windows to linux and my pushover for some reason is not working on some places.
i have a weather push that goes through and a news update that i had to trim otherwise it didnt arrive on my cell.
now i am trying to send an attachment file. when sending without the file, the push goes through but when attaching the file i get "Error POST URL Data at the root level is invalid. Line 1, position 1.".

any ideas?

The event structures may be different between the OS's which is why things may not work. Can you please attach a screenshot of your event with the attachment? Also if the file is not sensitive would you be able to send it me so I can verify that I can send it to myself?

[ez1976]

Hi
i moved my homeseer from windows to linux and my pushover for some reason is not working on some places.
i have a weather push that goes through and a news update that i had to trim otherwise it didnt arrive on my cell.
now i am trying to send an attachment file. when sending without the file, the push goes through but when attaching the file i get "Error POST URL Data at the root level is invalid. Line 1, position 1.".

any ideas?

[mrhappy]

Is there a way to automatically reset the Pushover message count at the beginning of the month?



Edit:
OK, this is weird, it did reset. I guess I never saw it on the first of the month last month.

I set this device with data from the HTTP header replies from Pushover when you send a message, some more detail is on their API page;

Once message limits have been reached, requests will be rejected with a 429 HTTP status code. Message limits are reset at00:00:00 Central Time on the 1st of each month. Per-day and per-month usage statistics can be viewed on each application's page, as well as through HTTP headers returned in each API call to the messages endpoint showing your app's monthly message limit (plus any additional purchased capacity), the number of messages sent this month, and the Unix timestamp of when the count will reset.
X-Limit-App-Limit: 7500
X-Limit-App-Remaining: 7496
X-Limit-App-Reset: 1393653600

[Dan-O]

Is there a way to automatically reset the Pushover message count at the beginning of the month?



Edit:
OK, this is weird, it did reset. I guess I never saw it on the first of the month last month.

[mrhappy]

Thanks MattL0

Sorry it was my auto correct that corrected ping to pick, your results are a little slower than I would expect (I get a ping of 88ms, I'm on a fairly average ADSL line) but it should not introduce a delay of that long. I will drop you a PM if that is OK to run through a few things.

[Pricey1985]

I think he want you to send a ping to api.pushover.net in the cmd.exe

i think the command in windows is :
ping api.pushover.net

Thanks MattL0

[MattL0]

I think he want you to send a ping to api.pushover.net in the cmd.exe


i think the command in windows is :

ping api.pushover.net

[Pricey1985]

OK can you go into command prompt and pick api.pushover.net and see what sort of times you are getting?

Sorry you have lost me on that one. Windows command prompt?
I googled how to send via cURL Windows command prompt and my head started to hurt.

[mrhappy]

No VPN, however i have 2 modems.
One is setup as an access point for all wireless connections.
HS pc is using this wireless access point.

OK can you go into command prompt and pick api.pushover.net and see what sort of times you are getting?

[mrhappy]

No VPN, however i have 2 modems.
One is setup as an access point for all wireless connections.
HS pc is using this wireless access point.

My fault my IP was incorrect on my Dynamic DNS - should be back up now.