Hi Dominic,
works like a Charm!
Can you kindly post your Code parts from your Sitemap ?
Br Peter
Hey @Peter_Aschinger
unfortunately I use that within rules and using the Rest API for my MagicMirror. But that should be easy. Simply format it within the Sitemap or utilize UoM (Units of Measurement)
Perfect, looks good 
1 Like
Hi Dominic,
let me ask a question:
In the .things file you defined the Settings Channel as a “string”
But the linked item is Type “number”.
Can you explain me that ?
Did you use that for setting dynamic the limit of the Inverter ?
Br Peter
Hey, sorry for the late reply, number should be fine, thats a mistake as i won’t use it.
Number:Dimensionless (Percentage) should be fine.
So i had a look into the documentation and adjusted my config:
The channels are listed here: https://github.com/tbnobody/OpenDTU/blob/master/docs/MQTT_Topics.md
// opendtu.things
Type number : inv1_limit_relative "I1 limit relative" [stateTopic="serial/status/limit_relative", commandTopic="serial/cmd/limit_persistent_relative", unit="%"]
Type number : inv1_limit_absolute "I1 limit absolute" [stateTopic="serial/status/limit_absolute", commandTopic="serial/cmd/limit_persistent_absolute", unit="W"]
// opendtu.items
Number:Dimensionless OpenDTU1_inv1_limit_relative "Limit (rel)" (ODTU1_inv1) {channel="mqtt:topic:default:OpenDTU1:inv1_limit_relative"}
Number:Power OpenDTU1_inv1_limit_absolute "Limit (abs)" (ODTU1_inv1) {channel="mqtt:topic:default:OpenDTU1:inv1_limit_absolute"}
1 Like
Thanks for that!
But how can i set the limit?
I did a selection widged in the sitemap like this:
Selection item=OpenDTU1_inv1_limit_absolute label="Limit (abs) W" icon="qualityofservice" mappings=[600="600W", 800="800", 1200="1200", 1500="1500"]
When i try to set a Limit i get a error in the log like this:
2023-05-08 20:11:22.611 [ome.event.ItemCommandEvent] - Item 'OpenDTU1_inv1_limit_absolute' received command 1200
==> /var/log/openhab2/openhab.log <==
2023-05-08 20:11:22.734 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.handleCommand()' on 'org.eclipse.smarthome.binding.mqtt.generic.internal.handler.GenericThingHandler@16cf43f': null
java.lang.NumberFormatException: null
at java.math.BigDecimal.<init>(BigDecimal.java:494) ~[?:?]
at java.math.BigDecimal.<init>(BigDecimal.java:383) ~[?:?]
at java.math.BigDecimal.<init>(BigDecimal.java:806) ~[?:?]
at org.eclipse.smarthome.core.library.types.DecimalType.<init>(DecimalType.java:57) ~[102:org.eclipse.smarthome.core:0.10.0.oh240]
at org.eclipse.smarthome.core.library.types.DecimalType.valueOf(DecimalType.java:71) ~[102:org.eclipse.smarthome.core:0.10.0.oh240]
at org.eclipse.smarthome.binding.mqtt.generic.internal.values.NumberValue.update(NumberValue.java:65) ~[?:?]
at org.eclipse.smarthome.binding.mqtt.generic.internal.generic.ChannelState.publishValue(ChannelState.java:302) ~[?:?]
at org.eclipse.smarthome.binding.mqtt.generic.internal.handler.AbstractMQTTThingHandler.handleCommand(AbstractMQTTThingHandler.java:119) ~[?:?]
at sun.reflect.GeneratedMethodAccessor729.invoke(Unknown Source) ~[?:?]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:153) [102:org.eclipse.smarthome.core:0.10.0.oh240]
at org.eclipse.smarthome.core.internal.common.InvocationHandlerSync.invoke(InvocationHandlerSync.java:59) [102:org.eclipse.smarthome.core:0.10.0.oh240]
at com.sun.proxy.$Proxy160.handleCommand(Unknown Source) [276:org.eclipse.smarthome.binding.mqtt.generic:0.10.0.oh240]
at org.eclipse.smarthome.core.thing.internal.profiles.ProfileCallbackImpl.handleCommand(ProfileCallbackImpl.java:75) [109:org.eclipse.smarthome.core.thing:0.10.0.oh240]
at org.eclipse.smarthome.core.thing.internal.profiles.SystemDefaultProfile.onCommandFromItem(SystemDefaultProfile.java:49) [109:org.eclipse.smarthome.core.thing:0.10.0.oh240]
at sun.reflect.GeneratedMethodAccessor728.invoke(Unknown Source) ~[?:?]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:153) [102:org.eclipse.smarthome.core:0.10.0.oh240]
at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:53) [102:org.eclipse.smarthome.core:0.10.0.oh240]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
What i´m missing ?..
BR Peter
Update:
i use the item without “:power”
Number OpenDTU1_inv1_limit_absolute "Limit (abs)" (ODTU1_inv1) {channel="mqtt:topic:default:OpenDTU1:inv1_limit_absolute"}
That throws no error anymore!
Sure, both is possible. The state and command topic are taking care that the Limit is set properly.
Another thing is, that you might use a combination of both. So when dealing with a HM400 and an absolute Limit of 200 Watts, that equals 50 % relative limit.
No need for the units, but more beautiful and accurate (YieldDay is in Watt-Hours, YieldTotal kWh, so I wanted to take care of it)
May it’s not OpenHab related but why is it possible to set the Limits with Watts or Percentage?
1 Like
Hi Peter could you explain to me how you did the sitemap with the graph i’m a beginner and have no idea how to store the data
What Version of OpenHab are you running ?
I´m still on 2.4 and i guess in Openhab 3.X its different.
But basically you need to persist with rrd4j your item to draw a graph like that.
i am on 3.4
Thanks!
Quick question: How do you avoid the status of the respective items going to UNDEF when the PV modules don’t deliver any power / the inverter goes into hibernation?
In my case, outside of the times when the inverter is powered on (see example below)…
… the state of the items goes to UNDEF, which does not look nice in dashboards (more a cosmetic problem)…
… but also causes problems when using the values as input for calculations in rules.
I read found this thread here but was wondering whether there’s a better way to do this? This thread here would solve the problem for “current power”, but overwriting e.g. “daily energy” to zero if the inverter goes down would simply produce wrong results.
Any ideas?
From what I can see, the easiest fix would be if openDTU would continue to submit the last value, even if the inverter goes down?
Try to use persistence.
I use RR4J/InfluxDB
Can you please specify?
I am using openHab 3.4 with InfluxDB already, still with the above described behavior.
It depends on different things:
Persistence strategy, whether the inverter does reply on messages after sunset etc. My inverter/s are set to be silent at night. This+persistence helps me to get no false values. I do reset certain values at midnight using a rule.
I do the same.
I am using an HM-600. From what I can see, there is no way for me to change the behavior of the inverter. 
If your inverter is set to be silent at night, you should be having the same problem I’m having (no response from the inverter → UNDEF in openHAB)?
Update: Maybe I’m looking at an MQTT problem / integration problem into openHAB. When running mosquitto_sub -h 192.168.0.150 -u username -P password -v -t solar/# the output shows the desired values even if the inverter is down (at night), so I have to check the MQTT channel tomorrow.
solar/dtu/status online
solar/dtu/uptime 23254
solar/dtu/ip 192.168.X.X
solar/dtu/hostname OpenDTU-30AAC0
solar/dtu/rssi -33
solar/dtu/bssid XX:XX:XX:XX:XX:XX
solar/inverterid/name Wechselrichter
solar/inverterid/device/bootloaderversion 104
solar/inverterid/device/fwbuildversion 10010
solar/inverterid/device/fwbuilddatetime 2021-11-01 08:42:00
solar/inverterid/device/hwpartnumber 269553683
solar/inverterid/device/hwversion 01.10
solar/inverterid/status/limit_relative 100.00
solar/inverterid/status/limit_absolute 600.00
solar/inverterid/status/reachable 0
solar/inverterid/status/producing 0
solar/inverterid/status/last_update 1690139392
solar/inverterid/0/powerdc 0.5
solar/inverterid/0/yieldday 1118
solar/inverterid/0/yieldtotal 109.306
solar/inverterid/0/voltage 230.8
solar/inverterid/0/current 0.00
solar/inverterid/0/power 0.0
solar/inverterid/0/frequency 49.98
solar/inverterid/0/powerfactor 0.000
solar/inverterid/0/efficiency 0.000
solar/inverterid/0/reactivepower 0.0
solar/inverterid/0/temperature 28.4
solar/inverterid/1/voltage 12.0
solar/inverterid/1/current 0.02
solar/inverterid/1/power 0.3
solar/inverterid/1/yieldday 521
solar/inverterid/1/yieldtotal 42.587
solar/inverterid/1/irradiation 0.000
solar/inverterid/2/voltage 12.0
solar/inverterid/2/current 0.02
solar/inverterid/2/power 0.2
solar/inverterid/2/yieldday 597
solar/inverterid/2/yieldtotal 66.719
solar/inverterid/2/irradiation 0.000
solar/ac/power 0.0
solar/ac/yieldtotal 109.306
solar/ac/yieldday 1118
solar/ac/is_valid 0
solar/dc/power 0.5
solar/dc/irradiation 0.000
solar/dc/is_valid 0
Solution: The flag “enable expiration” has to be disabled for the items to contain data without gaps when the inverter is switched off. I found the solution here on openDTUs Github page.
3 Likes