HIDDEN FEATURE!!! - https link for virtual switch

I see a virtual switch to control the volume.

That slider is tied to a rule with 7 steps of volume.

can you also show the http request please?

Sure. But please be aware that I have a nas that is running as a php webserver and is translating the command from zipato to onkyo. My onkyo had 1.10 at the end of my IP. 1.14 is my NAS address.

http://192.168.1.14/onkyo.php?command=MVL¶ms=20 (20 is the desired volume).

Attached the php text below. Add this into notepad, change the IP address to your onkyo ip address inside the code and save the file with extension .php. The file is inside a folder in the PHP webserver on my qnap nas.

1. <?php
2. $command = $_GET['command'];
3. $params = $_GET['params'];
5. $hostname = '192.168.1.10';
6. $port = 60128;
8. switch ($command)
9. {
10. case 'PWR':
11. case 'AMT':
12. case 'NTC':
13. case 'SLI':
14. case 'TUN':
15. $message = '!1' . $command . $params;
16. break;
17. case 'MVL':
18. if ($params > 60)
19. exit(1);
20. $message = '!1' . $command . strtoupper(str_pad(dechex($params), 2, '0', STR_PAD_LEFT));
21. break;
22. default:
23. exit(1);
24. }
25. print $message;
27. $fp = pfsockopen($hostname, $port);
28. $packet = "ISCP\x00\x00\x00\x10\x00\x00\x00" . chr(strlen($message) + 1) . "\x01\x00\x00\x00" . $message . "\x0D";
29. fwrite($fp, $packet);
30. fclose($fp);
31. ?>

Thank you, I have an Integra but they use the same control codes.

Works perfekt..

I don't see this. Only with meters.

Exactly. Only sensors have URL link. This is why this is a "hidden feature".

I just created a new switch and looks like the device descriptor changed, now there is no URL. It looks like this;

This is indeed very strange. I created a switch and i do get a link. See attached. There must be something different between us Alberto.

nevertheless when I use the link and hit 1 or 0, the change does not go though to the system. Im unsure if this is because my zipatile is currently offline or not, but I will investigate it.

On the other side I have one switch that has same response as you and I dont know what is the difference between the one I have link and the one I have not.

I have tried with both my zipatile and zipabox and both switches are missing the url. This indeed is very strange, what firmware are you on??

Also all my controllers just went online, maybe Zipato servers are down?

Im on 1.1.35. But I think this should not be dependent on the firmware version. Perhaps on the fact on what server you are logged into. I don't know.

Only zipato knows the true story and because this feature is not officially supported, we cannot even get it fixed...

Ok Alberto. Now the zipatile is back online. Tested the switch with the link and it works.

On the other hand:

The fact that while zipatile was offline the link did not work (i got positive response as below, but in the web ui was no change) means that the virtual switch is located on zipatile and not in the server. What I dont understand is that: while zipatile was offline, what did respond? and why on the web ui was no change, if there was a response. Or if the switch is on the zipatile, then why there was no change in the web ui if the cloud did respond.... guess only zipato knows the answer.

Did see the same issue. Tried some of your ideas and it did not work. Only virtual meters do.

Please check if you can change state of any newly created virtual sensor after upgrade to 1.1.35. All sensors I created recently show guid in web browser but no sensor state change works. In the same time sensors created few weeks ago work fine. So maybe it's not a matter of switch but general failure of virtual devices created after firmware upgrade 1.1.35

Yes I confirm that method described above works. You can change state of virtual switches from outside zipabox using URL. But it doesn't work for switches created since firmware update 1.1.35 as no virtual devices work after that update and all all rules that act on those devices are terminated.

Can you please elaborate on "since firmware update 1.1.35 no virtual devices work and all rules that act on those devices are terminated", as this may help me understand why some rules seem not to be working as expected.

I have several virtual devices - switches and sensors. Since I upgraded to FW 1.1.35 about 1 week ago, no virtual devices created since that time work. I can turn them on i web ui but with no result in the box, ie. after reloading web ui they are still off, no STATE history is registered for them and no rules are triggered by them. In other words this state change is fake as zipabox doesn't do anything except move slider from OFF to ON after click.

Second symptom is that when you use such virtual device in a rule it makes rule fail on action block with that virtual device - such rule is terminated. But rules on devices created on previous firmware 1.1.17 still work.

If you have such symptoms, open the ticket. I have done it, but the more people report problem the better chance they will fix that. This is serious problem.

To be more specific with "rules are terminated" - if the rule consists of steps:

When motion sensor is Active

1. Turn on light

2. Turn on a virtual device created after 1.1.35 upgrade

3. Do HTTP request with notification

4. Move up a shutter

Then result you get is a light turned on but no notification, shutter still closed and no virtual device state change.

Just sharing what I tried without success :(

If I look up a virtual switch that is working with a get /virtualEndpoints/{uuid}/config, the response is

{ "className": "com.zipato.network.virtual.http.HttpEndpoint", "hidden": false, "descriptorFlags": null, "description": "", "type": null, "uuid": "fac5bf56-b229-444b-aa4c-535c07b1799c", "room": null, "tags": null, "hiddenRules": false, "uiData": "{\"attributes\":{\"STATEurl\":[{\"name\":\"https://my.zipato.com/zipato-web/v2/virtualEndpoints/fac5bf56-b229-444b-aa4c-535c07b1799c/remoting/attribute/set?apiKey=xxxxxxxx&serial=xxxxxxxxxxx&ep=fac5bf56-b229-444b-aa4c-535c07b1799c&STATE=\"}],\"apiKeys\":{\"xxxxxxxxxxx\":\"\"},\"state\":[{\"name\":\"STATE\"}]}}", "name": "Maison occupée", "category": null, "status": null, "order": null}

If I look up a virtual switch that is NOT working with a get /virtualEndpoints/{uuid}/config, the response is

{ "className": "com.zipato.network.virtual.http.HttpEndpoint", "hidden": false, "descriptorFlags": null, "description": "", "type": null, "uuid": "a2639f5a-a5bc-4ea8-a5cd-5db29281e3a2", "room": 50120, "tags": null, "hiddenRules": false, "uiData": "{\"attributes\":{\"apiKeys\":{\"xxxxxxxx\":\"\"}}}", "name": "Ampli", "category": null, "status": null, "order": null}

There is a difference in uiData as the working swith has a url and not the non working one.

If I try then to do a put on the wrong switch by reusing the response of the working switch and the URL I am told to use from the non working swich, I am successfully able to update the config of the non working virtual switch to be aligned with the config of the working switch, but it still doesn't work !

This is the JSON I put for my non working switch

{

"className": "com.zipato.network.virtual.http.HttpEndpoint",

"hidden": false,

"descriptorFlags": null,

"description": "",

"type": null,

"uuid": "a2639f5a-a5bc-4ea8-a5cd-5db29281e3a2",

"room": 50120,

"tags": null,

"hiddenRules": false,

"uiData": "{\"attributes\":{\"STATEurl\":[{\"name\":\"https://my.zipato.com/zipato-web/v2/virtualEndpoints/a2639f5a-a5bc-4ea8-a5cd-5db29281e3a2/remoting/attribute/set?apiKey=xxxxxxxxxx&serial=xxxxxxxx&ep=a2639f5a-a5bc-4ea8-a5cd-5db29281e3a2&STATE=\"}],\"apiKeys\":{\"xxxxxxxxxxxxxxx\":\"\"},\"state\":[{\"name\":\"STATE\"}]}}",

"name": "Ampli",

"category": null,

"status": null,

"order": null

}

I suspect the solution is to change the settings of AttributeUrls, so that will be my next investigation. I need to find the rigth API for that.