I am trying to send the smart readings from dsmr binding to my Loxone. I am using a rule for this:
Nevertheless, the meter in my Loxone App is not being updated:
While in OpenHab the value is transmitted through the rule:
When using rules on light Items, I have no problems and status are updated correctly in Loxone App.
Any suggestion? Thanks in advance
Hi. The Loxone meter functional block is read only. It can’t be updated from outside of the Miniserver, it can only be reseted to zero. If you need such behaviour, you can try to create a Value Selector and use it as the meter value.
Hi @ppieczul, Thank you very much for having a look at this issue. I have now created a Value selector as per your suggestion and set up the Number channel for transmitting the value:
Still, the values are not transmitted to Loxone, although I would guess that the value should have been transmitted to the P input of the Loxone Selection Swich?
Anything else I can do to debug?
Can you post some logs from the binding like you did in the other issue? Thanks
See below log. I went through, but I could not find anything that makes sense… Maybe a problem with my setup? Anything I can do to verify this?
log.txt (160.8 KB)
Would you expect the meter values to be transmitted during this log? If yes, there is a problem that the binding did not receive any commands, so I would look in how the rule works, if items get updated and if items are correctly connected to the channels.
But there is something else unusual with that log, those sleep messages. There should be just one sleep message until something happens, but the sleep gets interrupted for unknown reason and goes to sleep again. It would be good to find a reason for that. Do you have OH2 or OH3?
Yes, I expected the meter values to be transmitted to the Selection Switch… I am using OH3.
I actually already tried different methods:
Anyhow, both methods don’t seem to work.
No idea where the sleeping comes from… I’m willing to investigate, but no idea where to start. Any suggestion?
I wouldn’t get involved with follow profile while you are investigating a problem, it’s confusing enough on its own. In particular, you will not get an events.log of any commands that it issues.
Stick to rule and sendCommand() to resolve the real problem, then use follow if you wish to replace the rule after it’s working.
From the logs it looks like the binding did not receive the command or a wrong type of command or to a channel that does allow to receive commands.
So things to check are:
what is the type of the command sent (should be DecimalType)
what is the channel that the command is sent to (should be number channel of the value selector control - not a dimmer channel, value selector has two channels)
has the command been dispatched to the binding at all - unfortunately I don’t have a log at the entry of command but you can enable some logs in the framework - I don’t know which ones though)
To make it specific, using following rule:
when
Item MainElectricityMeter_DeliveryTariff1 received update
then
LoxoneMiniserver_3CaveElecMeterDayTotalNumber.sendCommand(MainElectricityMeter_DeliveryTariff1.state)
end
MainElectricityMeter_DeliveryTariff1 item from dsmr binding has type “Number:Energy”:
Loxone Value selector: I created an Item linked to the Number channel (i.e. LoxoneMiniserver_3CaveElecMeterDayTotalNumber), also type “Number:Energy”
On below screenshot, you can see that the value of MainElectricityMeter_DeliveryTariff1 is well passed to LoxoneMiniserver_3CaveElecMeterDayTotalNumber, at least in OH. Value is the same:
Anything I am missing?
I also captured a log that may help for the sleeping issue log.txt (313.2 KB) . It seems that it systematically occurs after this event: [ket.common.events.AbstractEventDriver] - incomingFrame(BINARY[len=48,fin=true,rsv=…,masked=false]).
No idea however what it can mean…
I’ll get you a custom binding with logs targeted at these problems later today.
Can you install this binding: Dropbox - org.openhab.binding.loxone-3.1.0-SNAPSHOT.jar - Simplify your life
And run the same scenarios with DEBUG logs on.
To install you need to
Thanks. Please find attached the full log. log.txt (253.2 KB)
I think following is the interesting section:
Also, now the item in OH does not update any more to the current value but always remains 1:
Also good to notice, I had to add “as Number” in the rule.
Otherwise I got following log:
The conversion to Number was essential otherwise the binding did not even start processing the command.
Check your min and max values for the value selector in the Miniserver what are their values?
Also, the log.txt seems to be something else - just a dump of http exceptions.
Thanks
Well, actually, I thought that, if both items were of the same Number type, it was not needed, but maybe I am wrong… Of course no problem to leave it anyway.
It was min=1 and max=100 000. I now set min = 0 and also changed the size step =0.001. Don’t know if these two made the difference, but at least, the value is updated again in openhab, but still not in Loxone:
See also attached log log.txt (154.1 KB)
Different things:
Sorry, wrong logging.
Hello, I have managed to send data to loxone using Virtual Input.
Items file: Number loxBoilerOben "Boiler Oben [%.2f °C]" (gDatalog1m) {channel="loxone:miniserver:1..."} Number lox2BoilerOben "Boiler Oben [%.2f °C]" (gDatalog1m) {channel="loxone:miniserver:2..."}
Rules file: sendCommand(loxBoilerOben, lox2BoilerOben.state)
It is currently working in openHab 2.5.11, may be it helps.
comment -
referring to
someItem.sendCommand(otherItem.state)
openHAB can be a bit picky, a state type object is not a command type object even if it looks alike to us, e.g. ON or 3.14
This always works!
someItem.sendCommand(otherItem.state.toString)
someItem.postUpdate(otherItem.state) // because its a state not command
Hi @jclugeon , thanks for the proposal. I tried your suggested solution straight away. Conclusion is similar. The value is updated correctly in OH, but it is not updated in Loxone. So origin of the problem is likely the same…
To be able to modify the values in loxone you have to grant the user read/write access to the object in loxone.
@Joe_Vray the problem with sending updates to Loxone seems to be that the command that the binding receives is a formatted value represented as a string: 1234 kWh. This is ignored by the binding, since it expects a numerical value. I don’t know how to cause the rule to pass an unformatted value as DecimalType. The problem however seems to be in the type of command passed from the rule to the item and then to the channel.
The interrupted sleep messages are caused by state updates for controls which are not supported by the binding. You may look up your http://miniserver/data/LoxAPP3.json file to find out what type of controls have UUIDs:
147409E3-023C-3F60-FFFF3D261055B08D
1006ACBD-0330-DE16-FFFFDCFD3F3801B8
147409E3-023C-3F8B-FFFF49551EAA3D11
Maybe we can add that support if that is something useful.
