Effectively just pass an image url, and the smartphone app shows that url as the image in a notification on the smartphone app? Not expecting it to proxy any image data at all, just a raw passthrough so that there is minimal hit on the push service.
I know we can do this via alternative means such as messenging services etc., just wondering if the mobile app has hidden functionality to render image url notifications which could be leveraged by rule triggers.
Short answer is no. People who have that requirement tend to use Telegram.
Long answer? has this not been raised as a nice-to-have feature request in the past?
You can search the issues but keep in mind that the myopenhab service which enables the notifications is a free service supported through donations. Moving images around as part of notifications in addition to all the other traffic it has to support is likely to be a pretty significant increase.
Itās a change that also needs to be coordinated across four separate repos at the same time:
Given the amount of effort and coordination required and the fact that there are several alternatives already available and working with integration with OH I would not be surprised if such a feature were either rejected or no one volunteered to implement it. Itās a whole lot of work to reimplement something thatās already supported through add-ons openHAB has implemented.
Agreed.
However I wasnāt really thinking of moving āimageā data around, just text urls, ie not so different to text notifications. The responsibility of making sure the URLs are accesible via the internet as well as local would be down to the creater of the trigger.
So say my notification is āhttp://short.url/asdkjhdāā¦ and that is it, nothing less and nothing moreā¦ that doesnāt really take up much more bytes than āYour washing machine run is complete.ā.
The idea being that the client app simply renders the URL on client device, so the hit is the client deviceās network provider and not OHās donation supported āfree-serviceā.
That use case seems really limiting. Most of the people who have implemented images in notifications do so using frames or even animated GIFs and MP4s from one of their security cameras. And unless they are completely oblivious to how foolish it is, these will not be available through a publicly accessible URL.
Note though that you can send a notification with a custom icon. Actions | openHAB
No more foolish than throwing a selfie up on Instagram though in that case weāre talking immensely detailed crystal sharp pictures of oneās own mug, but I hear you.
Limiting it may be, but it does establish the concept/ideaā¦ like how many things in OH have been developed through to maturityā¦ a seed is plantedā¦ a couple of years later that seed became a tree.
Security of images again is an easily described caveat āplease remember if your image is accessible via a URL, it is potentially accessible by everyone who has access to that urlāā¦ I have no time for foolish individuals 
But if the seed is plantedā¦ in the future one could easily add some authentication, basic/digest across https etcā¦ so a notification can be wrapped with credentials that the client app then uses to access images on client device, nicely securely done.
Sometimes one needs to open the door, before even deciding where to go next.
I guess Iāll stick to XMPP for now then.
ā¦
To minimise impact/workload, if say the client-apps (ios/android), simply observed an incoming notification for commands, say ā[[IMAGE-URL]=http://badabish_local|http://badabong_remote]ā (supporting both local and remote URLS via a split character for example)ā¦ rather than display the notification as text, just throw up the image referenced by the URL as the notification. That impacts nothing āfor nowāā¦ indeed if uptake and usage of this feature gains more demand, then a work-item could be established to add authentication logic etcā¦ give it a year or so and we end up with a very rich and powerful client notification system which fits into countless use-cases.
For good reasons:
We only have limited volunteers that code stuff so if something can be done in an already working way, we tend to not want to reinvent the wheel when time can be spent on other things.
Not disagreeing with any of the above. All valid.
However I personally do not like to use public services to host my data, I use my own servers and storage, not a fan of the ābig-tech cloudā concepts, donāt use social media, donāt use messenging services I do not have control over, my data stays with me. (all motivated by deeply political views on control/monopoly/subjugation/censorship etc)ā¦
Back on topic, for those of us who do host everything ourselves in our own private distributed networks with reverse proxies where appropriate for HTTP(S) content, it is nice to be able to easily leverage our own hardware. For example at some point I plan to run my own openhab public server for notifications etc, not that my handful of notifications a day are draining any resources out there, just purely out of interest and total end-to-end control of my own smart infrastructure.
I put out purely a suggestion, open a small door, minimum impact, if the uptake soars then we know it isnāt just a handful who find it an extremely helpful feature. I would definitely go in and throw a couple of hours into it, but in my case I havenāt even got an ios and android dev environment running so would be a learning and time curve there with all my other duties.
PS. for me it isnāt the end of the world, I can leverage my own XMPP server for this. Itās just when I get asked by the missis āwhy do I need two appsā, I think, she does have a point.
Also agree with what you wrote, it just comes down to:
a. who will code it, see bounty below.
b. keeping the cloud free which means keeping data passing through the cloud to an acceptable amount. It is paid for by donations and membership, see Donate | openHAB
You can create a bounty on this hereā¦
Introducing BountySource for funded development - Announcements - openHAB Community
I guess you could look at suggesting:
You can create a filesize check and refuse to send the cloud any files larger than 2mb and perhaps that would be acceptable to use on the myopenhab cloud. Streaming cameras non stop via the cloud is something that wont be accepted, but a 2mb file max limit only on events/push messages, perhaps that would. I do not know but if you were going to start a bounty it would not be hard to get a yes/no on what would be be ok.
It is rather disconcerting when the rational behind not implementing something is āwe donāt want to overload a free-serviceā, when the solution can be something as elementary as adding a bandwidth limitation flag inside the myopenhab project - meaning for the live free service it can be locked to limit bandwidth and for those who run their own install of myopenhab the limit can be removed, also possibly add a paid subscription feature where bandwidth limit can be removed for paid accounts who prefer to not roll out their own myopenhab server.
The idea behind the text URL is that there is no load on the myopenhab server above and beyond regular text notifications, and that the actual client-apps actually pull the image for display on client-deviceā¦ the rational behind that is simply to get a feature out there very quickly without impacting any other development stream.
At a later date a more comprehensive programmable/scriptable notification system using parsers etc could be established, but that is a hefty development task and considering openhab already has a resource limit on available development hours, priorities etc, definitely something for the planning stage for now, for implementation in the future.
Do you know who maintain the client-apps currently? get their input before proposing a bounty.
Hopefully for the last time, as I have written this many times before.
For being a non-profit organisation, the openHAB foundation, who is running the myopenHAB infrastructure, cannot offer paid services.
I do apologise, I think it is one of those things that will keep coming up from new users when they are told the limitation is the free-service not the tech.
In this case I now know the foundationās standing, and you shall not hear me reference anything āpaidā related with any service offered by the OH foundation.
So this filters things down easily to a bandwidth limit for the free-service if the option of streaming image data is to be considered.
More the reason why I feel the text image URL for the client-apps to render is a better option to get things moving quickly.
Create an issue at the github link below, but as Rich stated it will involve changes to multiple repos, so it is going to be a lot harder then simply using Telegram that has way more features and works right away.
Issues Ā· openhab/openhab-cloud (github.com)
I believe the problem is not the free service, but more that we have just moved to OH3 and there are a ton of things on the to do list and not enough hours in the day for those that contribute.
Thanks @matt1
Though I do not believe my suggestion will touch any other repo other than the client-apps, my suggestion was:
To minimise impact/workload, if say the client-apps (ios/android), simply observed an incoming notification for commands, say ā[[IMAGE-URL]=http://badabish_local|http://badabong_remote]ā (supporting both local and remote URLS via a split character for example)ā¦ rather than display the notification as text, just throw up the image referenced by the URL as the notification. That impacts nothing āfor nowāā¦
So in effect all weāre doing is adding a little bit of parsing in the client-apps of the notification text and determining it is for an image display in the notification bar. Not complex at all, trivial, being a programmer on other platforms I do understand the workload of something as simple as this, sadly I am not an ios/android platform dev.
Could probably build on it with [VIDEO-URL] tags etc in the future too, keeps things very flexible and gives the designer of the configuration a great deal more control of notifications for client-apps without impacting all the repos, as this is purely a client app notification thing, not so different to how custom widgets work where the designer of the widget can hook his own URLs in embedded frames etc.
If I recall correctly, the openHAB Cloud Server notifications require the use of Googleās notification backbone for Android. The same goes for iOS and Apple. Even if you do host your own instance of the cloud server, you will be using ābig techā services to get the notifications.
Thatās a reason among many. I think the primary reasons are: 1. who will implement it? and 2. is it even worth implementing given that it duplicates functionality that already exists and will require a relatively large amount of work and coordination to pull off.
The myopenhab.orgās ability to support it is also a concern but I donāt think itās the primary one. But it is worth looking back at history and remembering all the problems that occurred on the cloud server with the IFTTT integration.
And no one is shutting the door. We canāt stop nor would we stop anyone who wants to try and implement this. I think Matt and my main point is that itās probably unlikely that someone will volunteer to do so. It would have already been implemented if that were the case. So unless you are willing to do it, or can recruit someone to code it for you itās probably not going to happen.
That addresses my point though. It does impact other development streams in OH. Itās an end-to-end problem. It canāt be implemented solely within the cloud service or the Android app. Your suggestion of just defining some new language of tags to help identify and distinguish between a URL that is a part of the message and one that should be rendered as part of the notification is insufficient in my opinion and it opens up a security problem (an app blindly pulling down and rendering any arbitrary URL it happens to receive in a notification with no validation). Mitigating that significantly increases the amount of work even if the quick and dirty approach were viable.
The best way to request features and report bugs and to get the feedback from the developers is by filing issues.
That is not and has not been the sole reason offered by me nor by Matt.
Also note my comment above, even if this were implemented, it does nothing to actually help you achieve your end goal because the actual notifications ride on third party services outside of the openHAB Foundation. So again, the value of the significant amount of work required to implement this is called into question since even were it implemented youād be no closer to getting notifications without using a third party service than you are now using Telegram.
I apologise for wasting your time gents.
Please donāt be discouraged, ask the question if it can be done and the best approach to set a bounty, and then set a bounty on it. I have only raised some issues that need to be considered before you create a bounty that may not be achievable. Best to speak plainly so the situation is understood, but please do not take it that your idea is not worth moving forward on.
We already have album art when a song changes playing getting sent across the cloud so similar things are already done. An easy way to create moving GIFs that are small in size is already implemented, if the bandwidth is OK then it is silly not to ask about this IMHO. As already mentioned streaming non stop video is not going to be approved, but a small 1mb file getting sent a handful of times a day from only 20% of people that have an account as a guess to what this would add up toā¦ My guess is the load on the server is not going to be a problem, but its not up to me and I have never seen any stats.
Iāll post the link I already gave a second time as it words the situation much better than I canā¦
This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.