Lamellas - run down and then tilt

ok i had “setOrientation” on repeat i guess it started looping because of seting it and finishing a command and so on…
and I had 1 time setClosure, 0


However this now does not work and shows nothing in the timeline anymore :confused:
I’m very confused, it does not work / tilt in the end, and has no entry at all in the timeline?

EDIT
forgive me I’m an idiot, I had it disabled cause of the loop lol…
ok needs some more tests, however 1 time it worked.

but now: this needs hard coding that and “setClosure, 0” card… shouldn’t using these be a bit more flexible @Adrian_Rockall ?

Flexible in what way?
All Flows are pretty much hardcoded.

You need to test the “Command Name” and if the status “Successfull” of that command is True. So two logic cards.

Make it work and then start elaborating if required. As appearantly this is already complex enough.

2 Likes

Sorry both for confusion - maybe some unclear statements from my side:

so I did exactly as requested and I think the setOrientation on repeat I got in the timeline originated from a loop that came out from set tilt and command completed…

This version now seems to work, I will test it throughout the day and then final report so you also know :slight_smile: (THANKS a LOT for the help thus far!)

With more flexible I meant, not depending on setting it to exactly 0, but also tilting when i put it to 50% or whatever, but I think I solved that with the “contains” version without the number in the end.

Now I pose the question: does it make sense to have a “when” card that is more specific to differend commands: e.g. when closure command completed and when tilt command completed or something like this that triggers only on that specific case to not have to use logic cards (including to find out what the exact string is).
So that in future other persons have it easier? Or maybe that would be to narrow? (just pondering here)

Mostly I am very happy I don’t have to solve this via putting time delays instead of clear logic :wink:

thanks again

I agree it would be nice to have the options in a drop list of the When card, but I don’t know what the messages are for every device, as some will have more options and some will have less or different ones. The app has about 68 drivers covering over 130 device types. The current system means it will work for everyone rather than waiting for me to add different rules. Also, this is the first time in 8 years of the app that this requirement has come up, so I haven’t had cause to consider it.
However, your use case is now firmly planted in my mind, so I will probably ponder on solutions for a while and maybe one day something will emerge.

Hey @Adrian_Rockall very appreciated! If I can help in anyway even if it’s just testing some stuff because you don’t have access to these specific motors let me know!

The idea is to provide basic building blocks which you can combine in the way you want. Otherwise the number of basic buildingblocks will explode.

Ok I guess I was happy a bit too early… :confused:

following 2 things:

  • I found out, that the end command name is always “setClosure, 0” no matter to which position you set it, so also if I send them all the way up in the end it’s posting “setClosure, 0”
  • sometimes when I click the circle starting from all the way in the top it runs 5-10cm stops and tilts - here I cannot figure out why it happens
    it just happened 1 time and I tried 3 more times where it did not happen again…

I will check item 1.
If you can catch item 2 in a log I will see if it points to anything.

can I let the log just running all time and then say the timestamp I see it happen? would that work?
because it’s really random, nothing I did different

It should be OK to do that. The log will only keep the last 200 records, so it shouldn’t use too much memory, but you will need to catch it before it is lost.

I can’t see how that is happening as the number after the , should be the position it was sent to in the range of 0 to 1, where half way would be 0.5.

The code is this:
executionCmd = ``${this.setPositionActionName}, ${value}``;
where this.setPositionActionName is the command and value is the parameter used in the command.

I suggest to add a second notification card after the logic cart to see if this condition is ever true. Because as it is now “setClosure” in stead of “setClosure, 0” the AND card is never true and the tilt command is never executed.
So maybe there is another flow which sends the tilt command.

I think it will always be true regardless of the position as the AND card uses ‘contains setClosure,’, so ‘setClosure, 1’ will also pass the test.

Edit: maybe that is the issue @Rocky_Lonigro is seeing when he says:

I found out, that the end command name is always “setClosure, 0” no matter to which position you set it, so also if I send them all the way up in the end it’s posting “setClosure, 0”

Right,
The logic card (not the AND card, my mistake) was “is exactly”. I missed that change.

1 Like

I just manually sent them from all down to like 90% - the timeline string i got is “setClosure” without any , and number

now I sent them all up and I got “setClosure, 1”

then I wanted to send them all down again and right now at 23.22.48 it happened again 5cm down stopped and tilted with “setClosure, 0”
I went right into the log and sent it: 956319724

I wouldn’t know what can interfere, no other motor in use at the same time or something…

@Rmb when the thing works and goes all down the tilt actually worked…

the Idea of having contains was to also trigger it when I put them to 50% or so

I understand now.

There are a few errors in the log: “UNKNOWN_ERROR”, “WHILEEXEC_OTHER” and “CMDCANCELLED”. On top of that the local connection is sometimes failing with “getaddrinfo ENOTFOUND gateway-…local”, which suggest either Homey or the Tahoma is having some network issue. Maybe the “setClosure” without a number was from the failure.

uff this is gonna be a hard one then - the homey is directly 5m besides my router, so I think we can exclude that.

the motor is in the first floor where I also have a WIFI repeater (mesh network)

the tahoma box is on the second floor about 5m above the motor

so technically there shouldn’t be any range issues here.

Any idea on how to test this propperly? is there any table I could see like the zigbee table in the dev tools to check the routes?