For a update and i think you already know…? I don’t think the sensor is connected to the hub, but directly on the io-motor. But the io-motor let’s the hub know it is closed due the triggering of the sensor, i think. Can you find that so it can be included in the homey flow by the sunshade “if…closed by sensor:”
I have published a new test version that should add the Lock State capability. It should show nothing under normal circumstances but will show the message form the device if it activated. There is also a flow trigger card for it, so hopefully it will work.
Did the sensor capability in the device page change?
If you still had the event log or information log enabled could you send them again.
Also maybe write the tag to the timeline to check if the trigger fired and the value it passed.
Sended log again.
Lock status didn’t change for a month.
P.S. Made a notification in the timeline. But there is nothing seen, so it is not triggered by lock-state.
I have published a new test version. This has extra code to trigger the flow instead of relying on the capability change.
I can’t see why the capability in the device didn’t update though, so if it still doesn’t work then can you send me the Information log after making it retract.
Thank you for being so active in this request. Appreciate it. But it is still not triggered and there is no notification in the time-line. I send you a log. In this log there is also the movement of the screen. I made a wrong choice on the remote control.
Your right that there is a log with the name “wind” by the io:PriorityLockOriginatorState. So it is logged on the hub. But maybe i do something wrong? Because the “vergrendelstatus” isn’t changed for a month. Even when it’s blocked by the sensor.
"timestamp": 1689372271500,
"setupOID": "********************",
"deviceURL": "io://****-****-****/13043575",
"deviceStates": [
{
"name": "io:PriorityLockOriginatorState",
"type": 3,
"value": "wind"
},
{
"name": "core:PriorityLockTimerState",
"type": 1,
"value": "30"
},
{
"name": "io:PriorityLockLevelState",
"type": 3,
"value": "userLevel1"
},
{
"name": "core:ManufacturerSettingsState",
"type": 0
},
{
"name": "core:OpenClosedState",
"type": 3,
"value": "open"
},
{
"name": "core:DeploymentState",
"type": 1,
"value": "78"
},
{
"name": "core:TargetClosureState",
"type": 1,
"value": "0"
},
{
"name": "core:MovingState",
"type": 6,
"value": "true"
It looks like the lock state only comes in the cloud events and I had a condition to ignore them for devices that are accessible locally. I have removed that condition in the new test version so try that to see if it fixes the problem.
I think you got it. There was a notification on the timeline and the lockstate is changed. That was for the first time in months.But i made a mistake in my flow, so i must test it tomorrow.
Is all else still local?
That worked. Perfect. It was indeed the solution. It is send to the cloud.
Thank you very much. This sensor is more relaible than using the weatherstation to see if there is too much wind. Because of the trees that surround the weatherstation. I only have one question. Do i see it right that the “blockstate” stays on wind even when it is unblocked? Because else i got lower my sunshade after when it is unblocked.
I sended a few logs. Maybe you can see the moment it unlocks the sunshade again.
I’m not home to look at the code, but I have a feeling I am checking fo 0 and the event has a value of “0”, so I’m looking a number as the time remaining and it’s proving a string. Maybe that’s the issue.
Yes, everything else is still local.
I have published a new test version that compares with “0” so see if that helps.
Thanks again. I will test this out.
It seems it wasn’t that. It seems it is not triggering anymore. There is no notification on the timeline.
But i can work around it so i’m already happy when it’s only triggered when there is to much movement on the sunshade. I can do a lot with better logic and countdown and work around it.
OK one more go 
It seems there was a glaringly obvious typo as I was check for “io:PriorityLockTimerState” instead of “core:PriorityLockTimerState”, so it would never find the event.
Great. It starts a flow again when to much motion is detected. I let you know if it is opening again when blockstate is off. But this is already more than good enough. Can i give a small donation for all your help, support and including the eolis 3D?
It worked. Thank you. It took a longer time to release the block state. I think because i made too many actions on the sensor. But when the lockstate was released i got a notification on the timeline. And i see that lockstate is released on the device. Something i didn’t see before.
Let me know if i can make a small donation.
1 Like
Since my Homey reboot last night, the Somfy app gives an error I have never seen before: certificate not yet valid. Logging in is not possible so all Somfy devices cannot ben controlled
