andrew, with what command from that api document can i retrieve that info ?
Yes. Youāve got it.
I had a dig into the KLF binding code, and I think there are two problemsā¦
-
The current code does not have a handler class for the GW_STATUS_REQUEST command, so this command is neither sent by the poller, nor (therefore) interpreted by the binding. Obviously one could write such a handler class, and add it to the poller scheduler; but that is more work than I had anticipated.
-
Perhaps a more critical problem is the followingā¦
- CommandOriginator == RAIN would tell you that at some time in the past, the rain sensor had moved the actuator.
- And CommandOriginator != RAIN would tell you that some thing else had moved the actuator.
- However if 1) CommandOriginator == RAIN was set, and 2) it stops raining, and 3) nothing else moves the actuator, then there is no clue if the rain stopped or not.
So in other words, it could tell you if the rain sensor was triggered, but it could not tell you if it was reset.
Hello,
in fact, the limitation values changes according to the rain / sunny state:
If you place an item with the limitation channel in any map, a Change will be triggered which can be handled by a ruleā¦
Rgds, Guenther
Ah. Thatās interesting Guenther. So in principle we could create a ārainingā Channel in the binding without much extra effort after all.
Does anyone have the latest firmware for the klf around? the update2.velux.com website seems to be down, and I have a device that runs version 1.x
archive.org to the rescue: Velux Firmware Update (archive.org)
Is there some curl command or a script i can use to query that rain sensor , so I get some kind of json back? Or is that too difficult?
I ma not using openhab for the moment, but interested in this rain state
Thnx
Hello Fabio,
it could be that there might be some scripts, but this is outside of the scope of this binding.
Regards, Guenther
its not possible anymore to just do some POST calls to it?
Early v1.x versions of the KLF firmware used an HTTP GET/POST JSON protocol. But the v2.x firmware uses a SLIP protocol; which is extremely complex. If you want to experiment you might look at this page ā but it is not for the faint heartedā¦
ok, thnx, will have a look
Hi,
I read this topic, it is very interesting.
@Aldohr and @ennergei did you got some news about the firmware dump?
Regards,
Hi,
Itās going at its pace. I donāt have much time to work on it though.
Currently, Iām working on understanding the boot process to boot a custom Linux image on the TaHoma. I managed to boot in u-boot so far. Iād like to boot Linux from a USB key to make things easier (no constant reflashing and more space for tools).
The system itself does not hold many secrets left now. Iāve got the big picture from the initramfs to the system and some folks of the Home Assistant community used my work to exploit the unused local API I found and were able to force it open. As the API is similar to the REST one which is publicly made available by Somfy through the cloud, they managed to connect a Connexoon directly to Home Assistant with minimal changes on the integration of he latter: Somfy Connexoon/Tahoma jailbreak - Share your Projects! - Home Assistant Community
Iām still aiming at a full specification of the protocol to be able to communicate with io-homecontrol devices with cheap generic boards for 868MHz communication. I was able to sniff communications using an RTL-SDR and decode parts of the frame (actually everything from OSI layers 1 to 3 roughly). But application layer still stays obscure and I did nothing on the pairing process for now.
Iāll keep you posted if I make any significant progress.
Regards,
Aldohr
Ah sorry. Actually I ran into the same problem when I dug out the project. If you have a serial connector (like a FTDI) with 3.3V output you can cheat by inputting the 3.3V VCC from the serial device into the CE# pin of the NAND flash memory. Iām not sure I traced the tracks correctly for the debug pads and the pad I labeled DBGU VCC is unreliable.
Hi,
Good to read you and to see you are still on the project.
I also swniffed communication using RTL-SDR. I used the GNU Radio project of Thomas Buck. I own Velux and Somfy roller shutter. I have a stranger behavior, frame format between the two brands seems different.
I donāt know whether it is a protocol feature or a problem with my set up (I am really new to GNU radio).
Being able to use a generic board like CC1101 would be a great news. I am curious to know how you decoded link and network layers.
@AndrewFG , @gs4711
It seems that the limitMinimum is always zero now in my OH version 3.2.
The rule below sends open and close respectively to an item which will know if it is raining on not.
//UdendĆørs regnsensor
rule "UdendĆørs regnsensor"
when Item KLF200VindueLimitMinimum changed
then
if(KLF200VindueLimitMinimum.state == 0)
{UdendoersRegnsensor.sendCommand(CLOSED) HomekitUdendoersRegnsensor.sendCommand(CLOSED)}
else
{UdendoersRegnsensor.sendCommand(OPEN) HomekitUdendoersRegnsensor.sendCommand(OPEN)}
end
If has been working fine for a couple of years, but the state is always zero now, which means the rain sensor item is never activitated.
However, I do not know if this a hardware failure in rain sensor in the Velux window itself. Any comments would be appreciated.
Edit: It was a bug in part of my rule. Everything is working as intended.
@EjvindHald, I assume that your post relates to the Velux KLF binding? And not the IO-homecontrol?
Assuming the former: Nothing has changed in the binding code since April 2021 (and AFAIK those changes did not touch anything close to the limitMinimum channels). Those changes made it into OH 3.1 Release in August 2021, and OH 3.2 Release in January 2022. So when you say āit has worked for yearsā, can you please be more precise about what was working on what version until when?
@AndrewFG : Thanks for getting back on this. And yes, I am sorry to not be precise, but I simply do not recall when I made this, and I have no history to look into. I think the rule has been there for approx. 2 years, but I am not sure.
When you wrote that nothing has changed, I tend more towards a hardware failure in the sensor itself in the window. I guess I need to try to open it just before rain and see it actually closes as intended.
I have just done a power recycle of KLF200 and restart of OH to rule out these options. But it is not raining now, so I will have to wait until that happens.
Edit: It was a bug in part of my rule. Everything work as intended.
Did you document this somewhere publicly accessible? Iād like to confront it to what I have seen in my own installation here.