Above host name is new feature introduced recently - this is cloud connection to Loxone without need of port forwarding, this is only available for Miniserver Gen 2, unfortunately even when Remote Connection is disabled in Miniserver Thing gets updated anyway.
Is there any chance to block Thing autoupdate or force Thing to keep settings? Do I need to change something in Miniserver configuration?
Iâve tried with old .things but I fail with .items :-/
I thought the automatic would have explained it somehow. But if you add it manually and later it gets changed, this is somewhat mysterious. There is no method to initiate it from the Miniserver to the binding. Maybe through the discovery mechanism, but how would that reach the thing, if it is manually created, it should not interfere with it. It would be great to track that scenario and see what exactly happens. Maybe you have some logs with debug level from around when the port gets changed?
Hi Guys, relatively new to OH but have some experience with Loxone having setup my main house and a second house. I am currently learning OH and have a setup and a Raspberry Pi 3. Currently I have installed the Tesla Powerwall Binding and the Loxone Binding and am receiving data from both. Good Start. My goal is to be able to pass data from the Tesla Powerwall to the Loxone system. Loxone currently doesnât support REST over HTTPS with self signed certificated hence the need for the Pi with OH to do this and pass the data along.
I am however getting hung up trying to write the rule to do this. Iâll provide as much detail as possible and would be ever great full if someone can point me in the right direction.
In Loxone I have setup a Virtual input called PiBatterySOE. I have items defined in OH from the Bindings as:
Number:Dimensionless TeslaPowerwallBatterysoe //reads from the Tesla Binding
Number:Dimensionless PiBatterySOE âWhole house / pi battery soeâ //from the Loxone Binding
I have a rule then defined as follows:
rule âupdate Loxone Battery SOEâ
when
Item TeslaPowerwall_BatterySOE changed
then
PiBatterySOE.sendCommand(TeslaPowerwall_BatterySOE)
end
I however get an error âType mismatch: cannot convert from NumberItem to Commandâ.
Thanks for the quick response. I now instead get the error âCannot convert from State to Command.â The updated code looks like:
//This rule will run everytime Grid power changes or 1 / second
rule âupdate Loxone Battery SOEâ
when
Item TeslaPowerwall_BatterySOE changed or
Time cron â0/5 0 0 ? * * *â or
System started
then
PiBatterySOE.sendCommand(TeslaPowerwall_BatterySOE.state)
end
OK. thanks for the help so far. I have found my problem and of course it was as simple as a syntax error in my item name. So now I have no compile time errors and I have a dummy variable updating correctly so my rule is working now. One step forward. The linked value through to loxone is updating in openhab now correctly on PaperUI and values are importing correctly from Loxone. I still canât seem to get data to go in the other direction however. any tricks to this? Like I said before, I have created a Virtual Input in Loxone called PiBatterySOE. The only change I have made in Loxone is to uncheck âUse as a digital inputâ as I am expecting a number not a Boolean value. I have also defined this linked item in OH as a âNumberâ. What else do I need to do or check? My updated rule FYI is:
when
Item TeslaPowerwallBatterysoe received update
then
PiBatterySOE.postUpdate(TeslaPowerwallBatterysoe.state)
end
and⊠donât know if this will work but here is the loxone image pasted in:
Fixed. Perseverance. Ok so I learnt a few things in the process. The main one being that you canât have your source item defined like Number:Power it can only be Number.
Once I changed the source number to be just a Number, and the Loxone linked item also to be just a Number it all works. Also had to change to sendCommand from postUpdate. Final code looks like:
rule "update Loxone Battery SOE"
when
Item TeslaPowerwall_InstanteousBatteryPower received update
then
PiBatterySOE.sendCommand(TeslaPowerwallBatterysoe.state as Number)
end
I am having similar trouble with my Gen2 miniserver. Did you find a way to block the configuration from updating to the junk address and port? Like you I have my miniserver configured as a manual thing, because I thought this issue could have been related to creation through the PaperUI. However here it happened again with it being an unmanaged thing.
Unfortunately my log did not catch anything in it related to the reconfiguration. I may not have the log level set deep enough to capture anything useful though.
Can you please set the log level to debug - login to the openHAB cli and give command: log set DEBUG org.openhab.binding.loxone
It does not happen with my installation. I need to find out how it may happen that the thing changes these parameters automatically.
Thanks
I think I figured this out - this bug is due to automatic discovery (as suggested by @ppieczul before).
You need to remove thing, add it manually through Configuration -> Things -> + -> Loxone Binding.
And do not press Add in Inbox - this will mess up your configuration. [Update]
@ppieczul
We can play around with automatic discovery - Iâm ok to break some things in my config
[Update]
Iâve tried again with Automatic discovery - Loxone Thing was ok even after long time.
The only thing that was changed since then is Loxone firmware.
This morning I changed the log level, and rebooted OpenHAB. Upon boot the Loxone information was correct, but after 3 minutes I saw a log entry pop up. Here is the log entry.
==> /var/log/openhab2/openhab.log <==
2020-05-03 12:30:11.122 [DEBUG] [xone.internal.LxDiscoveryParticipant] - Creating discovery result for serial xxxxxxxxxxxx label Miniserver @ 192-168-XX-XX.xxxxxxxxxxxx.dyndns.loxonecloud.com port -1
2020-05-03 12:30:11.122 [WARN ] [mon.registry.AbstractManagedProvider] - Could not update element with key loxone:miniserver:xxxxxxxxxxxx in ManagedThingProvider, because it does not exists.
2020-05-03 12:30:50.070 [DEBUG] [.binding.loxone.internal.LxWebSocket] - [1] Sending unencrypted string: keepalive
2020-05-03 12:30:50.071 [DEBUG] [ding.loxone.internal.LxServerHandler] - [1] Sleeping for 240 seconds.
@xeroiv is that when you have thing created manually or through inbox? I suppose manually, because the discovery did not find the thing ID.
Do you know why Loxone introduces itself through the discovery mechanism with the remote address?
@maciejt it would be cool to debug more what data is provided in the discovery update. Maybe this is an update that does not change the IP but amends it with a new one. Do you have any means of tracing that message? Like wireshark? I will try to look at the code and see if there are any traces in the upnp module or if I can add some traces to dump the structures when discovery happened.
@maciejt
I am using Config Version 11, Firmware Version - 11.0.4.29
@ppieczul
I have tried it both ways. Initially I had created the thing through the inbox, but when this issue popped up I deleted it and recreated through a things file. I do not know why it introduces itself through the remote address, but the new firmware apparently introduced a new feature related to remote connections which doesnât require port forwarding to be setup. It may have something to do with that.
@maciejt
I added it manually through the PaperUI since it wasnât initially discovered automatically, after removing the .things entry for it and rebooting OH. It then later showed up in my inbox with the incorrect address and port number, which was also reflected in the DEBUG log for the binding. I did nothing with the entry and now it is not showing in my inbox anymore, and I can not find any log entries related to it past that point. I will continue to monitor for issues.
