Thank you for your reply.
Yes, I’ve registered to their API service. Above are the URLs which open, lock, and unlock the lock (GET URL). I removed the actual lock_id, api_key, api_token and key_id. I don’t want the whole world to open my smart lock.
It looks like I have to „URL Encode“ the $apiKey and $apiToken variables. Is there some function that I can use to „URL Encode“ those variables? It’s always possible to „URL Encode“ the variables myself and use those values in the variable, that’s what I did now.
The PHP script ends with „bool(false)“, I guess this is the „var_dump($response)“. If I enter the value of variable $endpoint in an internet browser window the requested action will be executed. The PHP script itself doesn’t trigger anything, not sure if the PHP script should do that.
Thanks for your assistance!
Dennis.
Hello @ubittner ,
Thanks for your help so far. I was thinking about creating an Integer variable, with 3 possible values; 0 - Open, 1 - Unlock, 2 - Lock and creating three different php scripts, one for Open, one for Unlock and one for Lock.
I would have to create an action script that triggers the different PHP scripts. What is the best course of action?
Thanks for the action script. That was exactly what I had in mind!
Building a module? Isn’t that next level and for users who know what they are doing? I wouldn’t know where to start.
I think I know what you’re after using the webhooks for the state. The status (string) and trigger (integer) are not in sync. Is it somehow possible to update the trigger integer variable without creating a chicken/egg problem or infinite loop? The „Open“ action is automatically followed by an „Unlocked“ action. (Another option could be if the integer variable value returns to a „neutral“ position.)
Did you register already an outgoing webhook from Loqed to IP-Symcon? And did you also create a webhook for the incoming status data in IP-Symcon?
So you will get an information if the status of your lock changes.
I would use two variabels:
One for switching
One for the status
From my point of view both must not be synced.
Or you must use a “sender” to split between action and status information.
The control of the lock is the incoming webhook to Loqed, what we did with the curl.
I created a module, you can install it via the module control under core instances.
You will find the module soon via the module store.
Also you need at least Symcon Version 6.0 or higher.
You can control the smart lock, status updates are not included yet, but this will be our next step.
There is also no documentation at the moment, but I am sure you know what to do.
My next steps for you:
A manual status request should be possible:
Status. ATTENTION: you can only ask the status a few times per day, until you are rate limited
Can you check if you can get the right url and I need the result information of that.
So in your script maybe you have to replace „OPEN“ with „STATUS“, but I am not sure, var_dump is your friend for the result.
For the outgoing webhook (Loqed → Symcon) you need a valid Symacon subscription. Do you have one?
I had a good weekend, thanks! I hope you’ve had a good weekend too!
It also explains explains the late reply, I wasn’t at home.
Right now I have 2 working PHP scripts, one for the actions, created with your help, and one for the status updates, using the outgoing webhook. Maybe the script using the outgoing webhook gives you the needed information?
I will install the module right away!
Update: I’ve installed and tested the module. All commands are executed succesfully.
My idea is on the first creation of the instance we don‘t know the status of the lock.
So therefore we must get it manually.
For upcoming status events we could use the webhook for status updates.
I’'ve removed the API token and the Lock ID from the URL. „Lock ID“ is a new value, not yet defined in the module. „Device ID“ in the module is called „Lock ID (old)“ in the LOQED documentation.
I think we can confirm that the „status“ URL is different than the „command“ URL.