Posts by condiosz

    Hello,


    About saving modifications to the URL for a WebHook, I think you might have tried this only by verifying if the URL has changed when 'Apply Webhook', and then immediately viewing the URL again.

    The error box appears.


    However, please refresh your browser screen, go back to WebHooks and look at the URL.

    You will notice the URL has not been updated.

    Also, when I issue a command to change the state of a switch, I get the return information:


    '{"was_on":false}'


    Now, I'm not interested in what *was* the case, it should return if the action was successful, and the relay is now in the requested state.


    As things are now, I have to issue 2 requests. 1. to request the state (on/off, open/close) for the relay, and 2. a request to get the current state of the relay.

    Hi,


    Another small issue is that the API protocol in http sends Carriage Return control characters in responses, as such:


    OUTPUT='{"was_on":false}^M'


    There is no need for these Carriage Return characters :)

    (in unix, escape character '\r' )

    Sure!


    But, if WiFi and Ethernet cannot operate together, should there not be some exclusion rule for this?

    And if this is the case for those two, isn't it also valid for 'AP mode'.

    And Bluetooth.

    I do not know what the rules are, but if there are, then maybe it is a good idea to incorporate some exclusion logic (keeping the configuration, simply disabling the IF).


    Anyway, picture in attachment :)

    Something strange with the inputs. When none are active, this is the results I get:


    Code
    ζ /usr/bin/curl --digest -u admin:xxxxxx --request GET "http://172.16.2.121/rpc/Input.GetStatus?id=0"
    {"id":0,"state":null}
    ζ /usr/bin/curl --digest -u admin:xxxxxx --request GET "http://172.16.2.121/rpc/Input.GetStatus?id=1"
    {"id":1,"state":false}
    ζ /usr/bin/curl --digest -u admin:xxxxxx --request GET "http://172.16.2.121/rpc/Input.GetStatus?id=2"
    {"id":2,"state":false}
    ζ /usr/bin/curl --digest -u admin:xxxxxx --request GET "http://172.16.2.121/rpc/Input.GetStatus?id=3"
    {"id":3,"state":false}
    ζ /usr/bin/curl --digest -u admin:xxxxxx --request GET "http://172.16.2.121/rpc/Input.GetStatus?id=4"
    {"code":-105,"message":"Bad id=4"}

    Why is the return code for 'Input 0' "null" and for the others true/false.....

    Actually, when I access the device over LAN in stead of over Wifi (whilst both are connected to the same network), the Wifi stopped responding, even though the icon indicates it is still connected. Maybe this is a feature.

    And, "Webhook Edit" does not seem to save changes made to the URL.

    It seems, to update a URL for a WebHook, one needs to delete and create the WebHook again.

    "Apply Webhook" complains the Webhook already exists (which is true, but I simply wanted to update the modified URL).


    Hi,

    Thank you so much for that.


    Firmware version: 0.6.10

    Firmware build ID: 20210810-125223/0.6.10-g11bf9a3

    Web build ID: 1.3.0-HEAD+g941e9d9


    So far :) :


    1. for Ethernet (Eth) it's similar: it doesn't work

    Code
    curl -X POST -d '{"id":1, "src":"user_1", "method":"Eth.SetConfig", "params":{"config":{"sta":{"ipv4mode":"static","ip":"172.16.2.120","netmask":"255.255.252.0","gw":"172.16.0.1","nameserver":"172.16.0.1"}}}}' http://172.16.2.120/rpc

    result:

    Code
    {"id":1,"src":"shellypro4pm-xxxxxxxxxxxx","dst":"user_1","result":{"restart_required":false}}

    But the setting is not updated


    2. Authentication works well with

    Code
    curl --digest -u admin:password 'http://172.16.2.120/rpc/Switch.Set?id=0&on=true'

    for example, though it is a pity only 'admin' is allowd as name of a user.

    Also, I do not get any response, and have to relay on the curl exit code:


    Code
    {"was_on":false}


    Not a bug, just a remark :)

    Took me some time to figure out the new curl syntax with authentication.

    I have not found a way to use syntax in point 1 url yet, to send a valid command.

    This is no issue, devices that have a password are merely child protected :D
    Small remark is that since everything goes over http protocol, all is visible on the network with a sniffer.

    Finally, it is SO cool the device supports http callbacks. The PRO didn't and so had to rely on other methods to get the status of the relays in sync with the server.


    Further: Also cool is now timer in seconds in stead of minutes.

    And what a cool API spec documentation! It looks fabulous!


    I'll be testing the switch functionality a little bit later...


    Thanks again for your valuable information and sharing of this. I really do appreciate it!

    Hi,


    Since the Shelly Pro 4PM was released, I was wondering where Shelly wants to discuss issues found with this new device.

    Are we supposed to create a ticket for every single issue? That would create a lot of tickets :D

    The image below is for reference of one of many issues I found, where I am unable to enter a static IP address.

    It just always says 'invalid format', though I assure you: they are valid :D


    So, where to throw all the feedback? Anyone knows?


    Thanks!

    Should you not also open a case with UniFi? I have a large UniFi mesh, and none of the issues you mention. However, I am using only HD-AP's, not on WiFi 6. And everything works.

    Clearly, I guess this is an implementation issue on legacy support of technology with UniFi?

    Call Ubiquiti and open a ticket, they are extremely helpful people! :)

    I'm so sorry you are having this experience. I do not have such, and all devices I could make them work with my environment. Maybe it has something to do with your WiFi setup? Or some other reason. But I can vouch sincerely that one can get them to work reliably and correctly. It does take some research effort though, and really... for me that's kind of their appeal. That only imagination is the limitation when using Shelly devices. I currently have around 130 devices working together on my network, and also some devices from other vendors (like Gude GmbH). I must say, Shelly is best value for money I encountered.
    Yes, I had a few 'dead on arrival's and 'dead after only 3 months', especially where the relay is concerned. But then, these are such cheap devices, and I use so many, a dead rate is to be expected.

    But there is no way I could have engineered all this automation in my home without Shelly devices, at this price point.

    Note: I am not affiliated with Shelly in any way, simply a paying customer.

    Hi,

    How do I know what version (1 or 2) I have?

    I have a mix of these devices installed, and they are not seeing update (though there is one).


    Otherwise put, what happens when I upload the firmware of 2 to a device of 1st gen?

    Or how can I by software determine the generation 1 from generation 2?


    Thanks! :)

    Thanks, that's also my experience, except that once you set a login password (as mentionned above), the whole device grinds to a halt (web interface).


    Also, there's NO notification when the battery goes dangerously low, before the device stops working. Maybe it would be nice if there was an http action 'last thing I do before I die' :D