That’s because you are looking at the event log rather than the oh log
Ah, I saw the oh-logs got zipped now. I did not recognize the correct ones. My error.
Is there a way to return to unzipped logs. I can’t upload the .gz files.
I saw in the event.log, the the Positions always swap between UNDEF and the right value.
2022-06-28 09:54:59.409 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Hobbykamer_Position' changed from 100 to UNDEF
2022-06-28 09:54:59.425 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Hobbykamer_VanePosition' changed from 52 to UNDEF
2022-06-28 09:55:09.208 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Hobbykamer_VanePosition' changed from UNDEF to 46
2022-06-28 09:55:58.947 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Hobbykamer_VanePosition' changed from 46 to UNDEF
2022-06-28 09:56:09.306 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Hobbykamer_VanePosition' changed from UNDEF to 46
2022-06-28 09:56:48.991 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Hobbykamer_Position' changed from UNDEF to 100
2022-06-28 09:56:48.991 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Hobbykamer_VanePosition' changed from 46 to UNDEF
2022-06-28 09:56:59.086 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Hobbykamer_Position' changed from 100 to UNDEF
2022-06-28 09:57:09.795 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Hobbykamer_VanePosition' changed from UNDEF to 46
2022-06-28 09:57:59.504 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Hobbykamer_VanePosition' changed from 46 to UNDEF
2022-06-28 09:58:09.757 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Hobbykamer_VanePosition' changed from UNDEF to 46
This is also reflected in the interface.
Can you confirm that if you lift the shade, and then lower it again, the vane position always reverts to 100? If that is so, then I could “hard code” such a reversion…
It seems the status still swappes between the real value and UNDEF.
:31
I only hit the DOWN button once at 18:31. Went totally down then OK. events.log (2.7 KB) openhab.log.7.gz.txt (19.8 KB) openhab-1a.log (345.0 KB) openhab-1b.log (718.3 KB)
Ok. I will have another attempt on Thursday. Sorry for troubling you so much; without the device in front of me, it is really hard to figure out what is going on…
Andrew, I did some more testing using a rule. My goal was to let the blinds down and set the Vane Position.
I issued both command immediately after each other. The problem now is the blinds do not go down first but the Vaneposition is set and the down-movement is cancelled.
In my current setup (Somfy Connexoon) there is a special command for this. It is called ‘SetClosureAndOrientation’. It takes two values. One for the Position and one for the Vaneposition.
First the Position is executed; when finished the movement, the Vaneposition is executed.
This command is quite essential because otherwise you have to use a timer to calculate how long the movement will take, before issuing the Vaneposition command. This time is then dependend on the amount of movement the blinds make.
EDIT: I think I will focus first on getting it working with simple atomic commands. And in a second step I will focus on handling complex commands.
QUESTION: is it correct that you can tilt your slats even when the shade is NOT fully down? (Do you have a photo?) Reason why I ask is that I myself have HD Powerview shades, where the slats cannot be tilted unless the shade is fully down…
QUESTION 2: and if you move the shade to (say) 50%, then tilt the slats, then move the shade fully down (say) 100%, is the slat tilt position maintained after the move?
@GeVaSta apropos your rule resp. combined position and tilt command: one potential solution would be to buffer the commands for (say) 1 second, so that if two commands are received within that window the binding will combine them into one command to the hub. Do you think that would work?
To have it more reliable, a separate command for setting the position and the vaneposition, in one command, would be much better.
Combining two command to a new command, when they are close enough after each other, is timing dependent. I don’t think it will be as robust as a separate command.
I think these three command Position, Vaneposition, Position+Vaneposition, would cover all needs.
I have put the new test-JAR in the addons folder and stopped openhab and started it again.
First thing I noticed, the Bridge does not get online after such a reboot.
Only after unplugging the KLF and starting it, it connected. I noticed this behaviour before. It is visible in the logs.
The I left the setup alone for a few minutes to show the UNDEF behaviour.
Blind was fully down (100%) and50% open.
20:44:15 pushed UP and let run up.
20:45:00 pushed DOWN and stopped at about 3/4 down.
20:46:40 changed Vane to 60%
20:47:00 changed Vane to 0%
20:47:40 pushed DOWN and let go down.
This is unfortunately a “feature” of the KLF. The only workaround is to disable the bridge thing and wait a few seconds before doing the reboot (and then reenable the thing again…)
Thankyou for your logs. I will a analyse and get back tomorrow.
Ok. As mentioned before, I would like to get the atomic support for vane/tilt position fixed before I start work on such a separate command. So I have created a separate issue to cover this new requirement as shown below…
@GeVaSta again many thanks for the logs. These did help me to identify a timing issue in the binding. I have fixed that issue, and uploaded yet another new version of the JAR file HERE. To be honest I am not sure if this will have resolved the vane position state swapping problem, or if it was just masking something deeper. So if you could please test the new JAR again, I would much appreciate it.
PS do you have another problem with your shades ‘Werkkammer’ and ‘Slaapkammer’? I ask this because in your logs they seem always to have position = ‘undefined’…
PPS could you kindly help me with the answer to my two questions (requoted below)…
@GeVaSta for the combined “Set Main And Vane Position” command I am implementing an OH ‘Action’ named setMainAndVanePosition() that would be called from within your rule as follows…
rule "Move Main And Vane Position"
when
...
then
// note: 'velux:klf200:hubid shall be the thing name of your KLF 200 hub
val veluxActions = getActions("velux", "velux:klf200:hubid")
if (veluxActions !== null) {
// syntax: moveMainAndVane(thingName, mainPercent, vanePercent)
// thingName: is the thing name of the actuator to be moved
// mainPercent: is the target main position of the actuator (0..100)
// vanePercent: is the target vane position of the actuator (0..100)
// returns: true if succeeded, or false if an argument was wrong
val succeeded = veluxActions.moveMainAndVane("velux:rollershutter:hubid:shutterid", 75, 25)
}
end
Hello to all. I have to replace my KLF 200, because of dead hardware (after running without any problems for 2 1/2 years).
I bought a new KLF200. Set it as Interface and “seach for new products”. Before that I pressed for 3 sec the “prog” button of my already paired remote control (Situo 1 IO) and my rolloshutter (Somfy Oximo IO) “winked”, so it confirmed that it is in learnmode.
But the product search of KLF 200 does not find any products.
Do I have to reset (factory reset) my Oximo rollershutter first?? Maybe to get rid of the former paired KLF200 or the removal of the systemkey?
Thanks for any hint.
P.S. Firmware version of KLF200 is 0.2.0.0.71.0
P.P.S. Has someone also done a replacement of KLF200 and what were the steps?
Above case, (broken KLF200 hardware), leads me to the following question: is there a way to backup/restore the complete configuration via API? If so, could this be added to OH binding?
Not really. The KLF resp. the API do have a command mechanism called ‘controller copy’, but that is for copying from one KLF to another, so it requires you to have both units already in working order. There does not seem to be a mechanism for save to / restore from, a file.
