Haiku Haiku Helper Message Notifications

jharrell

Active Member
I finally got around to buying Haiku Helper now that I am slowly moving everything off my WHS with WL3. Of course it's great with the web interface and javascript scripting and push notifications.

However it seems that if I enable push for messages it sends notification even for ones sent with no beep even though it specifically says "Messages (Except message sent without beep)" for the option.

The way I use messages most of them are sent with no beep and are used to just display some automation state to keypads and Haiku main status screen(Motion Detected, Rain Sensor, etc.) stuff that gets annoying real fast for beeps. Only specific "important" ones I set to beep.

Of course I have complained about Haiku message handling in the past since it always beeps when it loads if it sees a new message even though the message was sent with no beep, and have argued it should never beep for an old message even one sent with a beep. The push makes this even more feasible since message with a beep will beep on my phone when they are sent and not hours later when I actually open Haiku while no beeps should be silent always.

Not sure if it's possible to just update the badge for message with no beep versus a full alert for messages with beep in the push API, but that would be a nice option as well. I would also imagine others might want notification for no beep messages, would probable be good to have two separate entries in HH push settings, one for beep and one for no beep.

Only other issue I have is the event list in the web interface is extremely slow locking up the browser for 15 seconds or more while it loads the event list. This is on Chrome with a fast PC. So I pretty much avoid the event list on the web interface, everything else is snappy.

As always though thanks for the hard work on Haiku
 
I finally got around to buying Haiku Helper now that I am slowly moving everything off my WHS with WL3. Of course it's great with the web interface and javascript scripting and push notifications.
However it seems that if I enable push for messages it sends notification even for ones sent with no beep even though it specifically says "Messages (Except message sent without beep)" for the option.

How are you showing the message, via automation logic on the controller? Can you paste the programming line you use?

Of course I have complained about Haiku message handling in the past since it always beeps when it loads if it sees a new message even though the message was sent with no beep, and have argued it should never beep for an old message even one sent with a beep. The push makes this even more feasible since message with a beep will beep on my phone when they are sent and not hours later when I actually open Haiku while no beeps should be silent always.

The way Haiku works, there is no easy reliable way to differentiate these scenarios. We'll see what we can do...

Not sure if it's possible to just update the badge for message with no beep versus a full alert for messages with beep in the push API, but that would be a nice option as well. I would also imagine others might want notification for no beep messages, would probable be good to have two separate entries in HH push settings, one for beep and one for no beep.

Its not possible to update the messages count without sending an actual notification.

We've never had a request to have the no beep messages forwarded, because things that don't beep usually are not important ;) Seems to work well this way. Of course, you can add a few lines of scripting code to forward the silent messages too.

Only other issue I have is the event list in the web interface is extremely slow locking up the browser for 15 seconds or more while it loads the event list. This is on Chrome with a fast PC. So I pretty much avoid the event list on the web interface, everything else is snappy.
As always though thanks for the hard work on Haiku

It seems like this is Chrome being slow. It is fine in Firefox, Safari and even IE. We'll see if we can do anything to speed it up.
 
How are you showing the message, via automation logic on the controller? Can you paste the programming line you use?

Could it be a firmware version issue? I have 3.7 and my controllers the old kind that can't be software upgraded I have to buy a new chip.

This is one of the no beep automation blocks triggering a push notification:


64. WHEN Front Motion ON
AND IF Front Motion IS NOT DISPLAYED
THEN SHOW Front Motion NO BEEP
THEN LOG Front Motion


The way Haiku works, there is no easy reliable way to differentiate these scenarios. We'll see what we can do...

I am going to assume the the following is true but I don't know your code and its been a while since I used HAI Protocol:
1. You know if Haiku is currently running and connected.
2. You know if a message is sent with a beep or not if you are currently connected to the controller.
3. When Haiku starts it polls the currently shown messages but cannot determine if they where sent with a beep or not and therefore always does a beep if a new message is being shown since the last time Haiku was online.

I argue #3 is incorrect behavior, old messages should never beep even if you did know they were sent with one, but you don't and either way it should never beep after the time it was originally sent. Imagine if keypads acted like Haiku, a message is sent with a beep while no ones around, hours later the user walks by the keypad to check system status and it starts beeping like crazy to the user with all the queued messages, this is essentially what Haiku is doing.

Beeps have little meaning later, they are intended to get your immediate attention if your not looking at a system interface, if you are not around for the beep it should not beep at you again later while looking directly at system status, it's not useful and can be very annoying. One difference of opinion seems to be you refer to messages that are shown as "unread" so I guess your premise is they are like an inbox, I don't agree and I don't think HAI's intent was that messages are "unread", they are either shown or cleared, there is no concept of someone having read them, they can be cleared manually or through code but you can't mark them "read".

Push notification for beeps makes this even more relevant, now when Haiku is not connected it can still be immediately notified of beeps and actually beep at the correct time and not later, this is good and how it should work but don't beep at me later when I start Haiku especially for messages sent with no beep, that's completely wrong.

Its not possible to update the messages count without sending an actual notification.

For some reason I though you could send notifications that just update the badge vs a full alert, but I guess that's all purely in control of the user on the phone in their settings, too bad.

We've never had a request to have the no beep messages forwarded, because things that don't beep usually are not important ;) Seems to work well this way. Of course, you can add a few lines of scripting code to forward the silent messages too.

That's fine with me, I feel the same way, I was just looking out for others who may feel differently ;). I forget about the rich scripting, that would be a good solution if someone did want to push a no beep message, of course for me right now all message are being sent anyway.

It seems like this is Chrome being slow. It is fine in Firefox, Safari and even IE. We'll see if we can do anything to speed it up.

I should have tried IE I just don't even think about speed issues anymore with Chrome it's always been the fastest browser for me which is why I switched to it some time ago. Odd that Safari's ok since they both use webkit. Probably something simple I hope.
 
I've looked into it and looks like it has to be sent without BEEP OR LED. Then it should not be forwarded. Unfortunately when sent just without a BEEP it is not distinguishable (the firmware does not send any info regarding this).
 
Well that's disappointing, but I suppose for the few messages I would want to push I can using scripting to push them instead specifically.

Does this have anything to do with my other issue with message handling in Haiku?

BTW really love the climate graphing including heat/cool run-time.
 
You need to send the message either with a BEEP or with NO BEEP for HaikuHelper to automatically forward it. If you do not want the message forwarded, you need to send it with NO BEEP OR LED.

Its not directly related to the general issue. We don't get the info from the controller, so in a way its related. However, the main problem is that Haiku/HaikuHelper use a state machine design. Its possible to work around, but would kind of be a hack.

Glad you like the runtime graphs!
 
Unfortunately I like the LED it lets me know something interesting has occurred when walking by a keypad but doesn't annoy everyone with beeps in the middle of the night etc. So I will keep push notifications for message off and script them if I need a particular one.

Still not convinced it would need to be a hack to decide whether or not to beep in Haiku so long as the controller sends that info to you. Just like Haiku knows which message to display it would also have the beep state of the message internally in it's data model. The state transition would be expanded to "message shown with beep" or "message shown with no beep" rather than just "message shown" as it is now.

Perhaps just a setting to disable beeps all together in Haiku might be an easy solution, because with Helper I will push important/beep messages with script and they will still chime based on notification settings instead. Not ideal but would satisfactory for my needs.
 
Back
Top