Beiträge von fredsbus

I am using lots of Shelly IOT devices in my motorhome/caravan and haven't had a great experience. To the point that I started moving device functionality away from Shelly to hardwired connections.

All my Shelly devices have been sort of problematic inside my motorhome/caravan, especially the Shelly humidity and temperature devices.

I previously sort of got some of the devices to work by moving my Ubiquiti AirCube to the other side of the motorhome

My back brain sort of finally kicked up a what if?

I searched the configuration of the AirCube and turned it’s transmit power down from 20db to 8db for the 2.4GHZ band and all of sudden my sort of flaky Shelly IOT devices now seemed to be rock solid!!!

I was able to move the AirCube back to it’s original location where it functions as a access point and a data switch.

I guess if you think further about it our motorhomes are just one big metal tube/echo chamber for WiFy signals...

[Blockierte Grafik: https://www.busconversionmagazine.com/forum/Themes/default/images/icons/modify_inline.gif]

Given that all shelly devices are Wi-Fi on the 2.4.Ghz band and people are reporting problems it seems to be environmental.

My experiences with firmware updates have been:

1. Sharing a wired internet connection with my HP laptop always works even when the shelly device is right next to the laptop.

2. My Ubiquiti Networks airCube Wi-Fi Access Point; updates fails if closer then ten feet from the Shelly device.

As environmental feedback my class A motorhome can be in a packed RV park or out in the desert with nobody around.

So any progress on these two issues?

1. Allow more frequent reporting period when externally powered.

2. Device stuck and reporting a static value that doesn't reflect current conditions?

Note I am seeing this from multiple H&T's.

Dang I see a lot of these types of messages. I have a class A motorhome with a metal shell and with the brand of wireless access point that I use, it is possible to be too close to the access point.

I reported this months ago. What I do find works is using an HP laptop to share a wired internet connection via WiFi, until I simply relocated my access point to the other side of the RV from my main concentration of Shelly devices.

So hey chime in with your access point type.

Sounds weird but depending on your access point, moving farther away from it works better. At least that is my experience inside of my class A motorhome.

I had problems updating firmware and was only able to get it to work by instructing my laptop to share a wired internet connection via Wi-Fi...

I have a amazon smart oven/microwave and it typically takes commands like "Alexa microwave for one minutes" if the door has been open and closed in the last two minutes.

Kind of really bleeding edge for this type of stuff. However I do have a Dyson AirFilter/Fan that has a built in MQTT interface that I control via Alexa and NodeRed automations.

I discovered that LG has a Wi-Fi dishwasher from a simple google search, not sure what it allows you to do with it.

I have noticed that my Shelly H&T's are unreliable if they are too close to the type of wireless access point that I am using.

The bedroom H&T is: 20210312-133748/v1.10.0-rc5-g1c546b5

[Blockierte Grafik: https://www.crystalpoint.com/cpdownloads/public/outgoing/Freds/StuckHT.jpg]

As you can see from the above graphic the bedroom sensor got stuck about 6:30AM, note it continued to report every ten minutes and I power cycled it around 7:40PM, at which time it will track the temperature until it get's stuck again. Note when it got stuck the report turned the heat on and I woke up sweating because it was too hot.

Ten minutes is too course of reporting period when you are using it for climate control in a small space. That's why I requested the ability to specify the time period...

OK, I am not a normal use case. However I do have some feedback.

My situation is that I am extensively using Shelly products for my caravan/RV/mobile home automation and have been observing patterns of behavior due to the changing environments that I experience.

My automation environment is controlled from custom automations implemented with node-red via MQTT interactions.

Things that I am controlling or monitoring with Shelly devices are:

1. Climate control using the H&T as the sensors with four of them in the following zones:
   • Bathroom
   • Bedroom
   • Kitchen
   • Living Room
2. Cooling control for roof air conditioners via Shelly 1PM's for:
   • Bedroom (Spills over to the bathroom)
   • Living room (Spills over to the kitchen)
3. Electric hydronic heating control when plugged into external power or load dumping when solar charging the house storage battery has reached full capacity and to not waste solar generation, again using Shelly 1PM's.
   • Hydronic storage tank 1
   • Hydronic storage tank 2
4. Power monitoring when running on solar to shutdown the high power inverter to save energy. I am using the Shelly EM with two sensors for split phase power. I.E. If total power consumption has been under 100 watts of AC power for ten minutes; then automatically shut off the inverter as it consumes 100 watts plus say 20 watts of parasitic AC power loads. Note: I also ping the laptop computer to see if it is online with as a priority load.
5. Shelly 1's as MQTT power signal indicators for:
   • External shore power input
   • Generator input power
   • External power is 220V split phase verses a 120v feed

Given the highly variable environments that my RV goes through I have changed my H&T's to be supplied with external DC power with DC to DC converters.

Since the H&T are running on external power, how about allowing the reporting period to configurable when external power is enabled? I understand that this firmware feature was removed to conserve battery power, which is not applicable when externally powered.

Allow the reporting period to be altered via MQTT as when I am running the air conditioner in the bedroom due to it being a smaller space; I get big temperature over shoots when cooling.

My further observation is that when I am in isolated settings with no one close by that could cause WiFy interference, everything works are expected.

However when I pull into a caravan/RV park when there are multiple access point in range; things start to act weirdly.

My bedroom H&T is furthest from the WiFy Access point inside of my RV. It sometimes seems to get into a mode where it is making reports (I record the last MQTT event update time via a node-red flow), but it is reporting an older value rather then a fresh reading of the sensors.

Power cycling the device restores normal functionality.

My other Shelly AC powered devices sometimes loose connectivity to the WiFy Access point/internal network for both MQTT and web GUI interactions. Power cycling the device restores functionality.

Note the last two posts should be a day apart. First one was still sitting the browser and hadn't been submitted.

OK, I have tested numerous other devices operating right next to the access point with no ill effect.

Only the Shelly devices are having a problem with proximity.

OK this is really weird!!!

I moved the WiFi access point about 7ft (2M) from its original location and now Shelly WiFi connections are functioning reliably!!!

If it is restored to it's original location then the Shelly devices start failing to connect to the WiFi network.

With the exception of the H&T's the non-responding Shelly devices are less than 3ft (1M) from the Ubiquiti Networks airCube ISP Wi-Fi Access Point.

Ok I have the following Shelly devices in a 40Ft RV/bus/motor home that has an aluminum/stainless steel infrastructure. Think almost faraday shield!!! The interior of the bus is mostly plywood in one form or another which the Wifi signal should pass though. Sometimes works, sometimes fails.

My current active Shelly devices are:

1 EA Shelly Power monitor for 240V/120V split phase power monitoring.

4 EA Shelly H&T's with external power.

2 Each Shelly 1's as simple voltage input sensors for:

1. Shore power input

2. Current power input source is 240V slit phase.

5 EA Shelly 1PM's four of which will automatically be online if the bus has AC power via:

1. Inverter off of house solar/battery storage

2. Shore power when in RV Park

3. Diesel generator

The house battery/solar system supplies always on Ethernet with POE to to:

1. Ubiquiti NanoSwitch Outdoor 4-Port PoE Passthrough Switch (N-SW)

2. Ubiquiti Networks airCube ISP Wi-Fi Access Point

3. Ubiquiti EdgeRouter X Advanced Gigabit Ethernet Routers (Teleport link to home and corporate LAN)

The airCube Access point is the connection point via 2.4GHZ for all Shelly devices.

Every Shelly device is configured for MQTT as inputs/outputs for Node-Red automations.

The major problem is that the Wifi, connection is not reliable!!! Maximum link distance is 20 feet...

It worked when I first developed the software and automations, mostly works when I am out in desert.

Fails when there is other possible 2.4GHZ traffic that it could hear or heck it might be the phase of the moon.

Another variable seems to be the firmware release where 1.9.X seemed to break everything on all devices.

I had to revert to 1.8.3 to get anything to work.

I would like to buy more Shelly hardware (looking at motion sensors), but thinking that I have gone down the wrong path at this point giving the lack of basic connectivity.

I will probably wake up shivering in the morning as I have used Shelly for my climate control and everything is falling due to flaky Wifi connectivity.

Note there is other devices on the WiFi network like tablets, TV's and other non Shelly devices that just work every time!!!

I am periodically having issues with multiple shelly devices after updating them all to 1.9.0 especially with with my H&T's.

I had to roll the H&T's back to 1.8.0 since they are part of my climate control and now will be doing the same with my other devices.

To restore connectivity for a short period of time under 1.9.0 I am having to power cycle the access point and the devices.

They honor the last command issued to them but drop off of the WiFi connection at some point and then never reconnect.

Here's the procedure I had to use in order to downgrade the firmware on my H&T's:

RE: No longer able to join Wi-Fi network

Ok I was finally able to step back 1.8.0 and restore my WI-FI connectivity. Steps that I had to take:

1. Connect my windows laptop up to wired Ethernet connection.

2. Share my laptop as a mobile hotspot.

3. Record the shared mobile hotspot (after removing the space in SSID designation) information.

4. Turn off the mobile hotspot sharing

5. Hard reset the H&T

6. Connect to it and ask it to join the shared mobile hotspot.

7. Do an IPCONFIG on the laptop to find the IP address which in my case was 192.168.137.1

8. Soft Reset the H&T it will blink and then stop blinking when it connects.

9. Scan the subnet in step 7 to find the H&T IP address

10. Connect to the new IP address to verify that it is online.

11. Visit the firmware archive page and select the version that you want. The page will give you an URL to execute.

12. Soft Reset the H&T it will blink and then stop blinking when it connects.

13. Immediately execute the URL for the update.

14. The LED will start blinking, wait for it go out.

15. Soft Reset the H&T and connect to it's IP address. Verify that the firmware has been downgraded. In my case it took two tries.

I have four Shelly H&T's that I did a recent firmware upgrade to 1.9.0 on and now they no longer connect to my Wi-Fi network.

I can reset them and get to the initial menu at the address of 192.168.33.1 but the joining the client network functionality no longer works.

I visited the firmware archive at:

https://smarthome-forum.eu/index.php?shelly-firmware-archive/

I have tried the downgrade procedure to the 1.8.0 and when I paste in the URL to the browser (chrome).

http://192.168.33.1/ota?url=http:/…HHT-1_build.zip

I get the following display:

{"status":"updating","has_update":false,"new_version":"","old_version":"20201124-091711/v1.9.0@57ac4ad8"}

However the the H&T blinks for a while and then stops blinking and never does the downgrade operation.

What is the correct procedure that I should use?

What is the procedure to use with a downloaded version of firmware?

I am using various Shelly devices in my motor home that are AC powered off of the house inverter. I have one device that controls charging of the house battery bank off of a shore power input.

For the firmware I have: 20200827-070450/v1.8.3@4a8bc427 which is reported to be the current version.

Using MQTT I subscribe to the online flag and receive the following message when the device comes online:

{"topic":"shellies/AcFeed-120V/online","payload":"true","qos":2,"retain":false,"_msgid":"f130e164.f3a0e"}

However when the device is disconnected from shore power I receive the Last Will and Testament message of:

{"topic":"shellies/AcFeed-120V/online","payload":"false","qos":0,"retain":false,"_msgid":"468fdf00.0e854"}

In the configuration for MQTT I have the following settings:

pasted-from-clipboard.png

As you can see from the above detail the online status message is not retained by the MQTT broker. Which leads to confusion in determining if the device is online, as the last voltage and power setting values are retained, even though the device is offline.

You have latest version of your device!