Beiträge von doron

Has this been resolved? Is there a repository for gen2 firmware images for ota?

Zitat

Ticketing the question to Allterco would provide a first-hand answer as to whether the app supports local-only operations.

If I remember correctly, according to other users, if you allow internet access for the registration process and then disable it again, local operation should work better.

I did go ahead and open a ticket. The official response was indeed that in order to add a device to the app, you need to allow it access to the cloud - temporarily. Then after it is added to the app, you can disconnect it from the cloud. As long as the app can see the device (i.e. on local LAN, or, I might add, via a VPN), it will be able to control it.

My experience with that is that without cloud access, the app behavior is hit-and-miss - sometimes it works sometimes it fails, so unreliable.

Hi folks,

Shelly Plus 1pm f/w 0.10.1 - seems like I can't leave the "gateway" field empty when setting a static IP address. This is required for a local-only setup, and has been part of the recent f/w versions for previous gen devices. It appears as if it was not added to the current firmware.

Any chance this can be added? Thank you!

(Workaround: You can specify a nonexisting IP address for the gateway. Needs to be on the local LAN and remain empty. This is suboptimal as the device will keep looking for it, sending out ARP requests and whatnot, and the IP address must remain unpopulated.)

Zitat

the third party app app for local used shelly ShellyPilot you know?

Thanks. I didn't know about it - will look into it - is it well supported, from your experience?

Zitat

The original app works better local, if you activate the internet once for setup in the app.

Ouch. Is this the official behavior? Is it documented somewhere? This behavior of the app seems to contradict the "Devices do not need to be connected to the cloud" statement in the app description.

Unless this is documented behavior, maybe I should open a support ticket.

Hello folks,

The Shelly Android app's description says this: "There is also an option not to connect your devices to the internet with local control mode. Devices do not need to be connected to the cloud or to send data there."

How do I activate local control mode?

I'm trying to add a Shelly device (in this case, a Shelly 2.5). It is already on my WiFi network; I use "Add a device by IP", and provide it with the IP address. The app successfully connects with the device and shows me what it is, but when I try to add it to a room it gives me an error message saying that it could not connect that Shelly device to the cloud.

I know that; my Shelly devices cannot access the Internet.

I must be missing something - how do I tell the app to use "local control mode" and not try to connect the devices to the cloud?

Thanks for any help or insight!

Thank you User-FF !

I love your post, and the post you linked to.

This is indeed my way of thinking: a system failure, be it cloud, WiFi or HA controller, should never impact basic functionality. The system is there to serve us.

When you get up in the middle of the night, a flip of a switch should be all that's needed to turn on the light, always.

The proposed design is supposed (intended...) to conform to that line of thinking:

• There's always a physical switch: light, shutters up/down etc., with traditional-style wiring going to the actual thing
• A Shelly actuator behind the electric switch
• Only secondary, overlay functionality is triggered remotely - be it via another wall switch, HA scenario or (shudder) an app
  • This e.g. allows for physical buttons like: "All lights off", "All shutters down" or "All HVAC off", near the door (leaving) and near the bed (going to sleep), and sw functionality such as "turn off all power consumers in the outdoor shed"
• No cloud(!)
• No phone (etc.) required for any basic function
• If HA or even WiFi connectivity is lost, then theoretically, the primary physical light switch would still be functioning the "old-fashion" way (due to how the Shelly device is configured). Only if the Shelly device behind a particular switch fails, will that switch not function
• Bad comes to worse, an electrician can just put away the Shelly device, reconnect the particular switch and it should work again (only locally, no remote turn off etc.)

My thinking was that this represents a good point of compromise between the pure "no HA gizmos required for basic home functionality" and the wish to have some convenient automation. That said, I'm very interested in your kicking the tires of this approach. As said, this is still in planning so anything can be changed, and this discussion is extremely helpful. Might be helpful for others going through the same thought process.

Your point about maintenance by an electrician is also well taken. Then again if we put this point as a must-have prerequisite, we will have not avoid any automation whatsoever at the basic systems - including all-lights-off, all-shutters-down etc. Is that what you're implying?

Hello 66er

Zitat

the number of Shelly itself is not a problem. I have over 90 in use.

Thanks. That's very helpful. Let me ask you though - if you were to design a power system for a new house, from the ground up - would you still choose this way? Or would you opt for another topology (e.g. even fully wired, such as Homematic Wired)?

Zitat

With the AP's there are some threads in which the users report problems (mostly in German). Try the search (activate German threads in your profile!) If necessary, Google Translate is your friend.

Just did and indeed people have issues there - seems like Shelly and UI are on it though. Need to have the setup thoroughly tested before installing.

Thanks again!

Hello folks,

I'm (re)building our new home and designing the power and networking (ground up). We like actual power switches etc. so my thinking is to place a Shelly Plus device behind each switch and in some of the power outlets, and a few Shelly Pros in the wiring closet.

This way, we can operate our home via standard switches but can still overlay with automated scenarios - kind of a hybrid system.

This type of design will bring the total to at least 50-60 Shelly devices in an area of ~200 sqm.

WiFi provision will be via a few Ubiquiti APs.

Is this a common / reasonable setup? Do people have this level of density of Shelly devices? Should I expect good performance out of this setup?

How about power intake (idle)? heat dissipation? other consideration I'm not thinking of?

Any insight (including "don't do that!!" - I can still change stuff around... ) would be greatly appreciated!

Zitat

Thanks, yes, but still my browsers are complaining when they access a server inside my local network.

So, I was wondering if you would know a solution for that

Thanks, though!

If the complaint you are referring to is the message about a server certificate being unknown when you connect to a local server via HTTPS, then you could solve it, but the solution is complex and messy and probably not worth it: You can set up a local Certification Authority (e.g. using open CA tools based on OpenSSL, or a Windows Server) and certify your private-IP web servers with that. But in is one of the cases where the solution might be worse than the problem you're trying to solve.

Some more data to try to shed light on this - here's what I get in the debug log:

1425402813 mgos_http_server.c:180  0x3fff36e4 HTTP connection from 192.168.xxx.xxx:52170
1425421868 json.c:420              RAM: 49272 total, 34492 free
1426177885 mgos_http_server.c:180  0x3fff326c HTTP connection from 192.168.xxx.xxx:55209
1426187619 switch.c:1107           Relay on pin 15 changed state 1 to 0
1426191796 powermeter.c:97         pm measure interval: 0
1426195700 powermeter.c:105        oneshot measure in 150
1428583362 mgos_http_server.c:180  0x3fff2cbc HTTP connection from 192.168.xxx.xxx:64001
1429069295 json.c:420              RAM: 49272 total, 34012 free
1431376822 mgos_http_server.c:180  0x3fff326c HTTP connection from 192.168.xxx.xxx:51865
1434098703 json.c:420              RAM: 49272 total, 34380 free
1434415321 shelly_ping_check.c:154 Ping 0.0.0.0 (2)
1437095872 esp_main.c:137          SDK: state: 5 -> 2 (3c0)
1437100286 esp_main.c:137          SDK: rm 0
1437105528 esp_main.c:137          SDK: pm close 7
1437111841 mgos_wifi.c:119         WiFi STA: Disconnected, reason: 3
1437115898 shelly.c:292            WiFi disconnected reason whatever, will reboot.
1437119946 arp_check.c:60          Rebooting
1437124878 switch.c:1208           Going to reboot!

This is when I turn the last channel that was "on" to "off" (could be done via the switch connected to "sw" or via web UI - same behavior). For some reason the WiFi station immediately disconnects, and the devices reboots - only to keep doing this in a loop.

Set one of the channels to "on" - everything is stable again.

Hi,

(apologies for a previous version of this post named "WiFi Issues" - the problem turns out not to be a WiFi issue, turned out to be a mis-diagnosis)

I'm evaluating Shelly products for home use, so I purchased a few different products and am experimenting with them.

I'm seeing a rather weird issue with the 2.5 switch. It's running the latest (1.10.4) firmware but the problem seems to have been there with the stock (2019) firmware as well.

When I connect to the 2.5 in AP mode, everything works well. Immediate web UI response, instantaneous operation (on/off/readout/configuration) - the works.

When I configure it to join my WiFi LAN, problems begin. The switch joins the network, but its response time is abysmal. Can take two minutes to draw an initial web UI screen (if it does at all). "ping" to it shows massive (over 40%) packet loss, and the responses that do get back take like 2000-3000ms (good reason for slow response...).

Investigating it I found that the switch goes into a reboot loop. It just keeps rebooting every few seconds. Extracting "uptime" from the API via curl shows it clearly.

Factory reset, reconfigure - same story.

What seems to resolve the issue is powering one of the channels on. Once at least one of the channels is "on" - the switch stops rebooting and becomes still and responsive. Both set to "off"- reboot loop resumes.

Any help will be greatly appreciated. Thanks!

condiosz , please see my previous post. TLS Server Certificates are applicable only to servers with both a DNS name and a public routable IP address. They have no use or effect in the local network (private IP addresses).

Hi condiosz , thanks for taking the time to respond.

In spite of the tone of your post (what a welcome!), in practice we might be on the same side.

I'll just assume you've met some "security guys" in the past who rubbed you the wrong way.

I'm a long time open source enthusiast, who happens to also have vast security experience. The Shelly ecosystem, which for me translates to (a) a stable, safe and reliable vendor-provided software suite that can be trusted by the less computer-savvy customer, combined with (b) an open platform for modding and hacking for those who know what they are doing (you, and probably me and others on this forum), with a vendor who actually listens to those more savvy customers - is what drew me into considering this platform to begin with.

While (b) above is where I (and probably you) will spend most of my time, (a) is critically important. Without it, things like this are just a matter of time. If you want the company to thrive, you don't want that. And it's really simple to solve (maybe it is in fact solved - note that I asked a genuine question, not posted a rant or even a critique).

The risks involved with my question above are two: (1) The payload seems to not be authenticated, which would be a real problem for OTA updates, and (2) the firmware is moved via HTTP, which just makes it all the more simple to counterfeit. If (1) were solved then (2) would have been less of an issue. The combination (again, if I'm right about (1) - as I said, I'm just assuming! My OP was a request for assistance) is an accident waiting to happen.

Even if I will never let the smart switch connect to the Internet - and I never will - the firmware I download from the vendor's website and other locations who do archiving of sorts can be trivially modified to include malware, which I will never know about. That can't be good. Please read on.

Zitat

Sure you have a point about all the technical points you are adressing above, and it is quite easy to ask these questions. However, I would also like if you could provide hints as how would you solve your points above, without making the user experience hell.

With pleasure. In fact the point I made in the question I asked is quite simple to solve, without any negative impact on users like you and me.

It's a bit awkward for me to presume, since as I said we've just met (Shelly and me that is), but since you asked (while attacking me), here's a sample solution. This type of scheme is quite widely used and is by no means special or unique:

(a) Digitally sign all payload (f/w etc.) that is to be carried OTA or downloaded from the vendor's website, with one of a few private keys whose public counterparts are hardcoded into the firmware.

(b) Have the firmware validate the OTA payload using the above signature, before allowing OTA to proceed.

(c) Have an "advanced / developer" type of setting in the UI, allowing you to override the validation in (b). "Allow unsigned OTA update" or something.

(d) Move the official f/w download sites to HTTPS (see below).

(This is with a wide brush - there are nuances to the above, all quite simple to address. Done that, multiple times.)

You now have a system that's (a) safe for the general, cloud-using public and (b) trivially hackable with no effort, either via the OTA API or via the serial cable, for you and me.

Don't think Apple - think Android.

Zitat

You see, for us to use https, we would have to buy certificates - official ones - which cost money, which are an additional hindrance to use (the general public) in using the software.

No, not at all.

First, meet Let's Encrypt. For the past 9-10 years, they've been handing out free TLS certificates. Feel free to use those anywhere (on a public routable IP address).

Second, what I describe above re HTTPS, is only for the official sources of firmware. The general public will only benefit.

Zitat

I would like you to insert malware in a firmware downloaded from Shelly, please do it.

No, you don't... Trust me on that one.

But one successful attack on just one site carrying the official firmware, is all it takes. Those things happen every day. Usage of HTTP only makes the attack surface wider.

Anyway to wrap up, I think we're seeking the same goals. Simple and secure out of the box, easy and hassle-free modification for the relevant crowd.

I hope the above somewhat reduces your "profound dislike for cyber sec guys". Then again, maybe not

Hi folks,

I'm new to Shelly products - quickly learning, testing the products and system for potential use. I'm a cyber sec guy and part of my testing is of this aspect. Hence also this question.

I've been looking at the various firmware packages downloadable via OTA and saw that they contain a digital signature component - this is critically important if you're doing OTA updates, all the more so since it seems that the Shelly OTA updates are being done via HTTP (and not HTTPS). I assume(...) that each device tests the sig against a vendor public key that is hardcoded in their existing f/w, and only if the signature matches, marks the incoming f/w package as valid and allows the update.

Now when I downloaded a 1.10.4 version firmware - e.g. latest SHPLG2-1.zip - and analyzed it, I could not find a trace of a digital signature. The zip file contains less files than in previous versions, basically just the manifest and bin files, and the manifest does not seem to contain such signature either. (It does contain SHA1/SHA256 hashes, but these do not validate authenticity - they can be used to assert integrity).

I'm sure I'm missing something - I don't find it conceivable that the vendor would remove such a critically important feature, and leave the OTA process open to trivial attacks.

Can anyone help me out here? Thanks for any insight.