@tomatopi We are still working on documentation. I know it has been a very slow process but we are adding what we can to the doc sites (v4 and v5) as well as adding scripts to our script-examples in GitHub.

We have an internal ticket to review this issue. I will update with findings, no need to send an additional ticket. Thank you.

Hello @mihairosu,

It sounds like your diagnosis is on the right track. Here are the most likely causes based on what you’ve described:

1. Check that the guest user actually has the Users role
   Since the point shows Users = checked and Anonymous = unchecked, the guest account must:

• Be successfully logged in
• Belong to the Users role

If the guest account was created manually rather than through the usual user-creation workflow, it’s possible it never received that role.
You can verify under Administration → Users → guest.

2. Confirm whether auto‑login is actually succeeding
   If your auto‑login fails silently, Mango will treat the session as Anonymous, and any point that does not allow Anonymous access will simply disappear with no warning.
   To verify:

• Open your dashboard URL in a private/incognito window
• Check whether Mango shows you logged in as guest

Also, your example URL uses:
autoLoginPassword=guest1234

But you mentioned the password is guest. If those don’t match, the login will fail and the session becomes anonymous.

3. For meta points specifically

• Meta data points inherit visibility from their own permissions, but their values come from underlying source points.
• If the guest user does not have permission to read one of the source points a meta point depends on, the meta point may appear on the dashboard but will fail to resolve a value.
• So make sure the source points also include the Users role (or whatever group your guest belongs to).

4. Version change (5.6.2 → 5.6.3)

• Since this was working before the upgrade, it’s worth checking the 5.6.3 release notes. There have been a few changes recently around role evaluation and anonymous access. Even subtle permission tweaks could affect dashboards that rely on auto‑login.
  https://docs-v5.radixiot.com/v5-release-notes-overview

Hello @mihairosu, Single data point not publishing from MangoES to MangoEnterprise, steps to try:

If other points on the same publisher are working but one specific point is not arriving on the Enterprise side, the most common cause is an XID mismatch introduced when the point was removed and re-added to the publisher. Work through these steps in order:

On MangoES:

• Go to Publishers and open the publisher sending to MangoEnterprise
• Find the entry for the affected data point and note its Published Point XID (this is separate from the data point XID, it typically looks like PP_xxxxxxxx)
• Confirm the data point itself is healthy: add it to a Watch List and verify it is receiving fresh values from the Modbus source
• Confirm the data point's Logging Type is not set to Do Not Log, some publisher configurations will not forward a point that has no logged values

On MangoEnterprise:

• Go to the Data Source that receives published data from MangoES
• Find the data point that is supposed to receive this value and open its configuration
• Look at the Point Locator, it will contain the Published Point XID it is listening for
• Compare this XID to the one you noted on MangoES, if they do not match, this is the cause

To fix:

• Update the Point Locator on the MangoEnterprise data point to match the current Published Point XID from MangoES
• Save the data point, then disable and re-enable the data source on MangoEnterprise to force it to reconnect

If the XIDs already match, also check:

• The data point and its data source are both enabled on MangoEnterprise
• The data type on the Enterprise point matches what MangoES is sending (e.g., both NUMERIC)
• The publisher on MangoES shows a healthy connection status with no errors

The remove/re-add step almost always generates a new Published Point XID on MangoES while the Enterprise side still holds the old one, updating the Point Locator on Enterprise is usually all that is needed

@Jdiaz-co said in Timeout to lock table systemsettings:

hello good,

I'm having a problem. I'm using Mango 3.7.7 and the application crashes every so often.

The error I'm getting is this:

ERROR 2025-10-27T08:26:50,187 (com.serotonin.m2m2.util.timeout.TimeoutTask.run:61) - Uncaught Task Exception
org.springframework.dao.CannotAcquireLockException: PreparedStatementCallback; SQL [select settingValue from systemSettings where settingName=?]; Tiempo vencido intentando trabar (lock) la tabla "SYSTEMSETTINGS"
Timeout trying to lock table "SYSTEMSETTINGS"; SQL statement:
select settingValue from systemSettings where settingName=? [50200-199]; nested exception is org.h2.jdbc.JdbcSQLTimeoutException: Tiempo vencido intentando trabar (lock) la tabla "SYSTEMSETTINGS"

I would appreciate any help.

thank you

Hello,

This error comes from the embedded H2 database: something is holding a lock on the SYSTEMSETTINGS table too long, so reads (like select settingValue from systemSettings…) time out and throw CannotAcquireLockException.

Common causes:

• Another process/tool (H2 console, external SQL client) connected to the same H2 DB while Mango is running.

• Long-running DB operations (backups, purges, heavy writes) that keep the table locked.

• Short default H2 LOCK_TIMEOUT (1s) causing normal contention to show up as errors.

Things to try:

• Make sure only Mango is connected to the H2 DB (no external tools while it’s running).

• Increase H2 lock timeout in env.properties/mango.properties, e.g.
  db.url=jdbc:h2:${ma.home}/databases/mah2;LOCK_TIMEOUT=10000

• Check logs around the crash time for other FATAL/DB errors that might be the real shutdown cause.

If this is a production system (not just a test setup), I strongly recommend:

• Migrating from H2 to MySQL (more robust under load and concurrency).

• Upgrading Mango to a more recent supported version if possible, to benefit from DB and stability fixes.

v5 Release Notes Overview

Mango 5.5.4 Release Notes (09/25/25)

access-control

• Live only cameras can now be accessed on-demand when motion detection is disabled.
• Added an option to limit the number of active camera readers simultaneously.
• Fixed reader and recorder timing, corrected camera view FPS, resolved reconnection issues, and improved livestream stability to prevent lag and frame loss.
• Live only camera readers prioritize UDP connections for better performance, automatically falling back to TCP if UDP is unavailable.
• Migrate to JavaCV-based video processing pipeline.
• VideoTransformer can be used with FFmpeg or JavaCV implementations.
• Bundles required native dependencies (OpenCV 4.9 / FFmpeg 6.1.1 via bytedeco) for simpler setup.

bacnet-ds

• The BACnet data source now uses the shared local device to emit an IAm message on initialization and listens for IAm messages from other devices to track certain properties.
• Previously, each data source performed these functions independently, resulting in unnecessary messaging.
• When a request for data to a device times out, only the polled points at that device are marked as unreliable.
• Previously, all polled points in the data source were marked unreliable, even if other devices were responsive.

radix-tsl

• Fixed an issue where Mango failed to start up when the TLS module was enabled.

@mihairosu - **Update ** Mango 5.5.3 has been released to the Mango Store yesterday on September 9, 2025.

v5.5.3 - Mango Store Download

v5.5.3 - Release Notes

@mihairosu said in Update core 5.4.1 core 5.5.2 failed:

mihairosu
2 days ago

I tried to update Core and all modules from 5.4.1 to 5.5.2 and now Mango won't start up. I don't have permissions

See link to ma.log file.

Hi @mihairosu,

Thanks for sharing the details and sorry to hear about the trouble after upgrading to 5.5.2.

This issue is related to a known bug that was introduced in Mango version 5.5.0 and will be resolved in the upcoming 5.5.3 release.

In the meantime, a workaround is available:

You can manually change the system setting for the alarm level of the system event MAX_ALARM_LEVEL_CHANGED directly in the database while Mango is offline. Here's the SQL command:

UPDATE PUBLIC.SYSTEMSETTINGS t
SET t.SETTINGVALUE = '0'
WHERE t.SETTINGNAME = 'systemEventAlarmLevel.MAX_ALARM_LEVEL_CHANGED';

This should help bypass the startup issue you're encountering. Once Mango is back online, you can verify the change and proceed with your upgrade path or if your not comfortable making this change wait for the Mango v5.5.3 release.

Let us know if you any further questions or if anything else comes up!

@SGAF Hello, you should be able to export the Meta Data Source and its points directly from the Data Source. Alternatively, you can use the Configuration Import/Export tool to export all data sources and/or data points and then make your edits. Please note that if you remove the XIDs from the Data Points and substitute the XID of the Data Source on the other system, new data points created during the import to the other system will be assigned new XIDs. As you mentioned, context points will need to be mapped. Thank you.

Hello @jcaballeroa, sorry for the delay on this topic but could you please open a support request at Radix IoT - Support? I would like to better assist on this topic but access to the files have expired. Also, have you tried to start a clean Mango v5 to see if you have any issue starting up Mango before upgrading?

@jcaballeroa You mentioned that you are testing Mango 5 in free mode. Could you please tell me how many data points you are using, and send the complete ma.log file again?

Additionally, assuming the server writes logs to /var/log/syslog, you might find more log entries related to Mango’s issues there. I often find the information I need in the syslog when Mango fails to start up correctly.

Thank you.

@jcaballeroa It appears the issue is related to this property:

pki.monitor.expiringSoonThreshold=25%

The problem may stem from unusual locale settings on your computer that do not properly recognize the percentage symbol (%). To address this, follow these steps in order:

Step 1: Modify the property

1. Edit the configuration file containing pki.monitor.expiringSoonThreshold=25%. Change this setting to the decimal format (0.25) instead of using a percentage, pki.monitor.expiringSoonThreshold=0.25.

2. Restart the Mango service to apply the new settings.

If the issue persists, proceed with Step 2:

Step 2: Check your locale settings

1. Ensure your system uses a standard locale, such as en_US, where the percentage symbol (%) is recognized correctly. Adjust your locale settings if necessary.

2. Restart the Mango service again to apply these changes.

Please implement these steps and let us know on the forum whether this resolves the issue. Your feedback is invaluable and can assist others experiencing similar issues.