Hi all,
Last week I migrated from the old version with submodules to the latest version with artifacts. At first everything seemed fine, I just noticed that the input boxes appear to be multi-row. When I tried to see if there is a configuration item to fix it I found that the button “+ ADD CONFIGURATION ITEMS” doesn’t work, nothing opened. Has anyone else had this happen or have an idea of what to check?
Thanks
paco
Hi!
Did you have any custom asset types in your custom project?
Can you still create assets of those asset types?
Because, if the asset type could not be found, or it has changed since the migration,
the asset will fallback to a “Thing” asset type, without any predefined attributes.
Whereafter, every attribute becomes a text field like this.
If you’re using an OpenRemote default asset type,
the only breaking change was in September 2024, for the ElectricityProducerAsset.
Other asset types didn’t change since March 2023.
I was just thinking that it might be due to the type of asset used, it’s the only one that fails. I have a CustomAsset type, but that existed before, didn’t it?
I guess now I have enough work to replace that type with another one, as well as replacing the ID of that asset everywhere it’s used.
Thanks Martin
No problem!
Synchronizing the asset type with the correct attributes should be enough to work again.
The asset itself still works, but it’s a bit inconvenient in the UI to work with. (as you noticed)
As an alternative, you can always manually modify the database as you wish.
Let me know if you have any questions, although I’m not a expert on this haha
I don’t know what you mean by synchronising the asset type with the correct attributes. My idea was to replace the CustomAsset with an OurgridBatteryAsset, but there is a lot of data associated with each attribute apart from the use of the asset ID in rules and API calls, so I have a long way to go. However, making manual changes to the database won’t be a problem. Just don’t forget not to delete the old asset before data migration 
Aaaah okay. Sorry for my misunderstanding 
Thanks Martin for your support,
it seems I fixed this problem, it wasn’t complicated, but it was laborious. In addition, the version change has caused other bugs that I have been fixing gradually. My first problem was identifying them. It is worth mentioning that (as experience, for other users):
The Write Value parameter now uses %VALUE%.
Ex.:
{
"state": %VALUE%
}
Where the Java code (I created my own custom agent) previously saved the correct timestamp, it now saves it with an additional two hours. It must interpret it as UTC, whereas previously it was local. Perhaps this is due to the change to Java 21.
There are still some strange behaviours that I can’t figure out. Hopefully, future version changes won’t cause so many unexpected errors, we can’t keep starting from scratch every time.
Now I need to get the app server up and running in production. I’ll see if I can find something in the documentation, if not, I’ll have to ask you again