-
-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Number value NULL after OH update/restart #39
Comments
Looks like this is related to #38 issue. Values updated during startup are not transferred to the OH core. Maybe it is system configuration related. Is your OH PC slow or high performance? |
Its not related to #38, the Simatic Versinon is never updated. All other internal channel like PDU, Areas, Request, Bytes are updated correct. |
Sorry, you are right is related to #38, after restart Simatic:bridge the value is updated. |
I think the all values need to be forced update on first run in OnChange mode. |
@docbender |
What about bridge item values? For example binding version? It is null too? What about your hardware? Is your hardware slow? I would need a log dump in OnScan mode to see when the data starts to transfer after PLC is connected. I'm interested in "openhab.event.ItemStateChangedEvent", where you can see value change from NULL. |
Bridge same behaviour the version still NULL as long as I pause/start bridge. |
Please collect log after OH restart with org.openhab.binding.simatic set to DEBUG level and openhab.event.ItemStateChangedEvent set to INFO level. |
Here the logs, interesant is that the channels with NULL value does not exist in the logs. after bridge restart:
after generic device restart:
|
Important records from your logs:
OH start is really slow. There is almost a minute between Simatic binding started and the Rule engine started. 12 seconds between PLC bridge initialization and Rule engine started. After the Rule engine starts, the OH event bus is usually ready (item values are updated). At the moment I don't know of a solution other than increasing the binding initialization time. |
I was thinking about the possibility to change binding start-level value. It is set to 80 for all bundles as default. You can check it in karaf console with this command:
All bundles start in parallel. I tested starting with a higher value and it seems that this should be the solution for your problem. Try to increase binding start-level from karaf console with this command:
|
Thanks for the investigation but this doesn’t solve the problem. |
Opps the bundle:start-level was reset to 80 after restart, so I can not test it in this way. |
Addon loaded from OH addon folder is started first as you can see in console bundle:list command. This can be only affected by increase value of start level. This behavior does not occur in a standard binding installation. I added binding into marketplace and if it is installed from here, binding is launched last. To install binding from marketplace I recommend:
|
Hi, |
This whole is OH core behaviour. Obviously a lot happens in OH after an update, like creating a new cache, resulting in further delays in system startup. |
Hi,
I have observed that after every update/restart OH the Number value are not updated on first run, the values remain NULL as long as the value not changed on S7 or I’m restart the thing manually from UI.
It looks like the values are not updated on first start.
The text was updated successfully, but these errors were encountered: