Slow server response during screen editing

4 years ago in bOS Server • updated 4 years ago • 4

Hi,

Editing some frames, suddenly the server started to answer very slow. In the end the configurator showed me an "out of memory" message. I was able to start again the configurator but the server was still moving very slow. Even the commands to different equipment were sent with delays. I've restarted the server and now seems to be OK.

It first starts showing me different messages like the one below and at the end crashes showing the "out of memory" message. I've reported the same in a previous post ("out of memory bug") with some more screenshots.

By the way, are there any limitation in the number of displays defined on a bOS Colibri server? Does anybody have some limitation list for this (number of devices, number of programs used, etc...).

Regards,

Laurentiu

Vote

Replies 4
Oldest first
- Newest first
- Oldest first

4 years ago

Hello,

which server is the configuration running on? If the project is too big for our smaller server to handle, out of memory error may occur. You can find the approximate limitations in the attachment.

Also, It always varies from project to project, some project can have many devices with small usages or larger number of devices with smaller group address number, so we cannot provide the exact number, but as it's stated on all of our servers, what kind of project they should be used on..

Best regards.ComfortClick Servers Recommendations.pdf

4 years ago

Hello,

The project is running on a COLIBRI server.

Thanks for the limitations table. One question. As this is actually happening when I'm configuring the screens of the HUE devices and only for the HUE devices (everything else runs smoothly), the table says that COLIBRI server is limited to 2 HUE devices. I just assume that when you are saying 2 HUE devices you are talking about the HUE bridges not about the HUE lights. Is it correct?

It is true that I have designed a lot of screens as I'm trying to cover as much installations as I can. Is there any limitation in the number of screens which can be managed by different servers? I'm trying to link the devices via TCP/IP when possible (API calls, etc.) and I don't see in the table any limitation on that.

What would then be your recommendation? Is possible to split the application (I'm talking about having a unique HMI for multiple servers)? Is it better to run the application on a normal computer with Windows (I assume that in this case the limitations are somehow given by the computer hardware which is running the bOS server, correct?)?

Thanks,

Laurentiu

4 years ago

Hello,

yes, the table is referring to HUE bridges. Hue recently changed API for connecting to their bridges, so the connection now may not be working or causing issues, but we're already fixing the problem within our HUE driver to make the connection work so you can expect a fix/update soon.

We don't have an exact number for limitation regarding visualisation size, but if you start to receive these errors and slow configuration, it seem you're slowly reaching the limit and we recommend to upgrade to a more powerful hardware.

bOS itself isn't too hardware demanding, you can check our grinder/grinder black specs, which are recommended for larger projects and build something similar if you want to use your own hardware with a license.

Best regards-.

4 years ago

Hello,

Thanks for your answer.

I'm still wondering why is this happening only when I am updating the frame designed for controlling the HUE lights. Maybe it has something to do with the API changes that you mentioned... Looking forward for the update.

If I'm using external controllers (connected as HTTP devices) for example for Z-WAVE and I am controlling the devices through API calls, those devices are not causing the same load to my server as if they would be directly connected. Is it correct or I'm missing something?

Thanks for the recommendation for building a good server.

Best Regards,

Laurentiu

Customer support service by UserEcho