I’ve only just started with OH2 (I had played with 1.8 before but started over recently).
I don’t think (not sure) if anyone has shared what the actual problem(s) is(are) with my.openhab.org but based on my observations, I’m thinking that the load is growing exponentially as users increase and so do the number of available bindings / addons.
I’m surprised that users are able to, without restrictions, send ALL of their items over to myopenhab by specifying a * in the myopenhab.persist file. I think this is an approach that may (or may not) have led to the incredible load that must plague the servers.
Does everyone really need to have all of their items synced to myopenhab every minute? This is even more relevant on new installs for new users - new users don’t have solid understanding of items and the frequency of updates as well as its potential impact on upstream systems. I mean, does everyone really need all of their weather details and astro sun details persisted to myopenhab by default?
What if there was a constraint put into the binding (retroactively) that doesn’t allow a blanket persisting of ALL items?
I suggest that users have to explicitly set which items they want to expose to myopenhab. I would go so far as to say to make the change to legacy bindings and publish a warning that this change will be implemented on XX date. The new binding could send the data to a different vNext endpoint or the myopenhab endpoint looks for a new message structure and rejects anything that doesn’t fit the new version. Users would need to update their binding(s) in order to continue seeing updates in myopenhab.
There may be other issues that I’m not aware of but I think the fact that all items, from everyone’s setup being synced every minute (or on every update/change) is a bit much, given what myopenhab seems like it’s actually meant to do. I haven’t noticed any impact on the ability to use the rest/items endpoint and the UI via myopenhab.
The problem was an unexpected spike in traffic that has not been explained nor a solution found. The spike in traffic did not follow the growth us users and apparently the servers are not built such that throwing more hardware at them will solve the problem. Hence the delay in addressing the problem.
At least that is what I’ve gathered from postings from those in the know on this forum.
That could be though the unexpected spike makes me think there is more to it than that. Obviously a best practice would be to not send all Items to my.openhab though I will admit when I first set it up that is what I did until I became more comfortable with how my.openhab works.
That could be a good approach. I’m a little ambivalent about it though. On the one hand it could reduce the amount of traffic pounding on the servers, but on the other we don’t know whether or not that is actually the problem and it essentially “breaks” my.openhab persistence.
The powers that be have already expressed interest in treating my.openhab as something separate and special so I’m almost willing to accept having a separate way to configure it from persistence and that separate way would still allow including Items by Group but disallow including all Items.
That may not fix all the problems as users could just create an All group and use that, but it might help guide people down the path of a more sensible configuration.
I really don’t like just breaking the .persist file for my.openhab only though. If we are going to treat it as different then by golly lets make it different.
I personally do not share any Items to my.openhab any longer since I found IFTTT integration to be unsuitable for what I needed.
This could cause some problems. Oh the wailing and gnashing of teeth that occurred when they changed the SSL/TLS cert on the my.openhab servers and we discovered we all needed to upgrade our Java. I’m still seeing and fielding questions and complaints about that these months later. Making an additional breaking change to my.openhab will stir up that same hornet’s nest once again. I wouldn’t recommend going down this path unless it can be definitively confirmed that it would solve the problem.
Ultimately the real solution will be to re-architect the servers so they can scale with the growing OH user base.
