Pimatic Max connection error

---

My router (FritzBox-7490) provide a switch for every LAN connection.

Mhh that’s no solution for me. The router is located in another room and has no free ports left.

@TeeS has running his cube at a 100MBit switch and has those errors too.

Tests that I made so far:

1. Connect Cube via Fritzbox 7490 with 1Gbit option > Error messages like EHOSTUNREACH, EHOSTUNRESET…
2. Connect Cube via Devolo dLan200 PowerLine > No error messages
3. Connect Cube via Fritzbox 7490 with 100Mbit option > No error messages

I bought a managable switch and limited the cube’s port to 100M, still getting those errors.

I think I can reproduce those errors. Create a rule and send a command every 10 seconds to the cube. You will get “cube is busy” errors.

I got this because I have three heaters in my room and have a rule like

if bla then set temp of heater-1 to X and after 10 seconds set temp of heater-2 to Y and after 20 seconds set temp of heater-3 to Z

Sometimes the third heater doesn’t get the configured temperature because…“cube is busy”

I think we have to distinguish between Cube busy and error messages like “EHOSTUNREACH, EHOSTUNRESET”.

The reason for “Cube Busy” errors could be also the “Duty Cycle” for 868 MHz devices. “EHOSTUNREACH, EHOSTUNRESET” is from my point of view more related to physical incompatibility or driver issues.

When the cube was “busy” the last time, the duty cycle was at 51%.

Today my whole flat was cold when I came home. None of my heaters was hot because my 6 o’clock rules didn’t work. “cube is busy”.

Really annoying.

Is there a chance to resend the command when there is no positive answer from the cube?

You can create a rule that check periodically the current setpoints against the target temperatures and resend in case of mismatch.

No, this is no solution for me because there are lots of possibilities when the setpoint could change. I already have 11 rules for each heater.

In my opinion this should be handled in the callback function of the plugin where the command is sent.

If an error is thrown, wait some seconds and try again. The intervall and retry count should be configurable.

Indeed the a callback with retries would be perfect, however if you update in every rule a heater related register with the current target temperature of the heater than you can easily compare with the setpoint of the heater. I use this for window open detection to avoid resending for every window open event.