Beiträge von Amiga500

Moin Zusammen,

ich habe noch etwas mit meinem Fazi/Rückmeldung gewartet, um ganz sicher zu gehen.

Seit weit über 2 Wochen betreibe ich meinen Pro4pm mit der Firmware 0.11.4 nun ohne einen Reboot des Shellys

Ich verwende ioBroker mit dem Shelly-Adapter und habe extra die Abfrage auf 5 Sekunden runtergestellt, um den hier besprochenen Reboot zu provozieren, was mir aber nicht gelang!

Also von meiner Seite aus ist das Problem mit den Reboots nicht mehr vorhanden! Endlich

Zu dem anderen Thema "Abschalten wegen OVERCURRENCY" (da gibts ja noch einen anderen Thread) kann ich erst wieder im Sommer was sagen, da meine Zisternenpumpe im Winterschlaf ist

Grüße...

Zitat von SalvaBarcelo

I have the same problem with a vacuum cleaner and Pro 4PM.

Even after installing the RC snubber according to the instructions, the output switch off and shows "overcurrent" message.

There is no solution to this problem?

Hi,

unfortunately I could only improve my problem, but not solve completely!

In my case two connected devices have made problems to the PRO4PM.

1. device: on relay0 a GARDENA 5000/5 LCD (water pump). so nothing that you could call exotic.

after i installed the rc snubber, the overcurrent message comes only every 10 times, not every 2 times anymore.

I have also tested rc snubbers of different types and capacities. no noticeable difference!

2. device: a magnetic valve is connected to relay2. Here it came every time to a freeze, if the valve was switched off. I was able to solve this problem with a rc snubber. since then the switch off works without problems.

all in all, the PRO4PM seems to be very sensitive in all aspects.

In the meanwhile I have also lost patience and I have switched to homematic to control the Gardena pump....

cheers

Zitat von pustelbaer

...

1. Die aktuelle Beta-Firmware bringt keine Verbesserung bezüglich der Abstürze.

2. Ist die ioBroker Adapter-Instanz deaktiviert, treten keine Abstürze auf. Dabei spielt es keine Rolle ob im Shelly MQTT aktiviert ist oder nicht.

3. Aktiviere ich den ioBroker Adapter (der Shelly zeigt dann bei MQTT den Status "verbunden" an), treten wieder Abstürze auf. Dabei scheint das im ioBroker Adapter eingestellte HTTP Polling-Intervall eine wesentliche Rolle zu spielen. Mit dem Standardintervall von 5s habe ich mind. zwei Abstürze am Tag. Erhöhe ich das Intervall dauert es länger. Mit der maximal möglichen Intervallzeit von 86400s läuft der Shelly jetzt seit drei Tagen stabil.

Ich vermute das die Abstürze beim HTTP Polling auftreten. Hier scheint der Adapter turnusmässig ein Login am Shelly durchzuführen. Evtl. kommt es hier zu einm Überlauf oder der Shelly hat ein Memory Leak, etc. Es könnte aber auch mit dem anschliessenden http-Request zusammen hängen.

hi pustelbear,

I think I have a Dejavu .

Sounds like my description from March this year (same thread): RE: ShellyPro4PM Schaltet sich aus

Ok

once the pump is switched on, it runs smoothly (it has not more than 2000Watts).

It is only when it starts that it often behaves as follows

Unfortunately, I cannot confirm this. I also get the message "current limit is set to null".

But the function is not disabled.

When the page is reloaded, the values from before are back.

there is also the part "consumption type". Does anyone know what this is for?

Maybe it influences the switching behaviour or the sensitivity?

Zitat von thgoebel

Sorry, didn't check this yet! Assumed there is an "enable button" with voltage and current...

hi. I can only enter values from 0-280V respectively 0-16A. Unfortunately, there is no off button as with the power protection. 0 is also not interpreted as "off".

Hi, I have just tested it.

Switching off the limit did not bring any change. There too, "overcurrency" comes up and the channel direct is switched off again.

good morning,

I bought one of these rc snubbers from the shelly shop and installed it yesterday (directly at the consumer, connected in parallel according to the instructions).

Unfortunately, this did not solve my problem. The Pro4PM continues to switch off with "overcurrency"

Does anyone have any ideas what else I could try?

Btw. before the Shelly, I used this plug PCA301 (Link) with the same pump and it has a max. of 13A!

hi,

no, unfortunately not yet. can you recommend one RC snubber?

hello everyone, hello @mircho.mirev

It has become a bit quiet in this topic, so I wanted to describe my current situation.

After my tests with LAN, I have been back to WLAN for about 2-3 weeks, which was actually not the aim of purchasing this device!

But even with WLAN I regularly have a reboot every few days (with 2 existing PRO4PM devices). The uptime never gets further than 3 days max!

I have also noticed another problem, that my connected cistern pump often triggers an OVERCURRENT, although I have never been able to monitor values above 2000 watts. Here is my contribution to the problem:

Beitrag

RE: Overcurrent message

hello ruvigo ,

were you able to solve your problem?

I have a similar problem with a cistern pump.

The shelly goes into "overcurrent" very often, but not always.

The maximum power consumption at start-up is 1400 watts.

I have set the max power protection in the shelly itself to the highest value, which is 4480 watts, far from the 1400 watts of the pump.

I am currently at a bit of a loss and would be grateful for any useful tips.

Cheers

Daniel

Amiga500

9. Mai 2022 um 14:12

All in all, I am less and less impressed by the Pro4PM at the moment, as it simply does not work reliably.

I hope that something will happen here...

Cheers

Daniel

hello ruvigo,

were you able to solve your problem?

I have a similar problem with a cistern pump.

The shelly goes into "overcurrent" very often, but not always.

The maximum power consumption at start-up is 1400 watts.

I have set the max power protection in the shelly itself to the highest value, which is 4480 watts, far from the 1400 watts of the pump.

I am currently at a bit of a loss and would be grateful for any useful tips.

Cheers

Daniel

hello @mircho.mirev

I could now repeatedly find in my environment that it has nothing to do with MQTT, but with polling via http request. I have set the interval of the ioBroker shelly adapter to the maximum 86400sec and the shelly uptime is now more than 8 days. So no crash, no reboot. Everything that "comes and goes" via MQTT works perfectly.

I also contacted the developer of the ioBroker shelly adapter and he sent me the part of the code that sends the http requests.

Here is the link to it: https://github.com/iobroker-commu…er.js#L402-L841

Unfortunately it doesn't say much to me as I'm not a programmer.

In the end, I can name the following conditions for my tests that cause or contribute to the problem:

Communication via LAN + ioBroker in virtual environments, i.e. via VLAN (e.g. MACVLAN in Docker as in my case) + http requests at shorter intervals (e.g. 15, 30, 300sec).

Now the question to Shelly, whether there are any further news in this regard?

Many greetings

hello jonas,

what do you mean with indirect?

If there have been no reboots so far and the system has been running for almost 40 hours and you have increased the poll interval, then the relation is direct.

i also don't think that a reboot occurs with every poll via http. so if you only poll once in 24 hours, the probability is much lower than if you poll every 10 seconds.

Or have I misunderstood something?

cheers

daniel

hello jonas,

here is the url to get the uptime: http://shelly-ip/rpc/Shelly.GetStatus

you will find the point quite far down. the value is in seconds!

Otherwise, I have set the channels so that they switch back to the last known state after a reboot. under the channel settings, select "Restore last - Configure Shelly device to Restore the last mode it was in, when it has power.

I don't know if this works, but I'll see when the next reboot comes.

cheers

hello jonas, hello all

i am using Shelly firmware 0.10.1 and ioBroker adapter 5.3.2.

As I wrote earlier (post148920), I have tested a lot, but until today I can only speculate what the problem is related to. something more at the end of the post.

I can't confirm two of your points, but I can confirm the rest.

First, all channels show volts on my shelly and second, i see a direct correlation between the poll interval of the http requests and the soft reboots.

Since a few days I have set the maximum poll interval of 86400 seconds (one day) in the ioBroker adapter. Since then it has been running for almost 4 days without a reboot, which I check via the uptime display via API!

Ok, some general information are at least 1 day old, but everything related to MQTT works as it should. For me at the moment but only a workaround, because the problem still exist!

Can you test it to set the poll interval to 86400 and report? What is your ioBroker running on? Docker? VM?

Now shortly to my tests. I had hoped that it was related to the vSwitch setting of my Synology. Unfortunately, disabling it didn't bring any improvement.

The only relation I definitely see is the communication via MACVLAN of my Docker-Container. If the Docker is running on the host network, there is no soft-reboot.

I hope Shelly continues to follow up on this....

cheers

hello all,

I think I've made another step forward.

In the meantime, I don't think that MQTT is the main problem, because the reboots (formerly freezes) depend directly on the set polling interval via HTTP from the ioBroker Shelly adapter (see screenshot).

If I set this to very short intervals, e.g. 30 seconds, the reboots occur quite quickly!

If, for example, I increase the retrieval interval to 10 HOURS, then the reboots hardly occur or at the earliest after 10 hours!

All MQTT things, such as consumption, on/off switching, etc. work perfectly within these 10 hours without rebooting!

As always, I can only speak for myself, but it is repeatable!

Otherwise, I suspect a configuration of my Synology, which could also explain because it was also reported in other virtual environments, such as Proxmox. This is "Open vSwitch", which has been activated on my Synology for some time. Whether it has something to do with it, I can only test tomorrow at the earliest.

I will report...

Hello Mircho, hello together

After long tests, I think I'm one step closer and have been able to narrow down the "problem".

As reboots continue to occur at short intervals, I have carried out further tests.

Since my ioBroker is running productively on a synology in a Docker, I tried to outsource ioBroker.

For this I set up an old raspi with an iobroker test installation in my network. The connection to the Shelly was stable, there were no reboots!

Then I set up another container with an ioBroker test installation on my synology and connected it via bridge network (ports released, etc.).

Here too, the Shelly ran stably, no reboots!

But now it comes. My productive ioBroker runs with a MACVLAN by default. Therefore, the next step was to integrate the test Docker via MACVLAN.

It didn't take long and the Shelly showed the problematic behaviour again and rebooted at short intervals.

This leads to the assumption that it has something to do with the MACVLAN.

Can anyone confirm this who also had the freeze problems with the Shelly? So that your ioBroker is also operated in a Docker with MACVLAN?

Many greetings