Inexpensive system to start with - Seemple/Homematic/Fibaro and others

Nix wrote:

.... So it is the case that the AP is (simplistically) just an advanced programmer, yes, it supposedly controls the actors, but only by a pre-planned schedule ...

.
Oy ... schedules are stored in the devices (e.g. in the headsahc, in the room thermostats, in the sockets) and only in those that have them. Unless (which I don't know about because I don't have an AP) for actors without their own schedule, the harmomogram is saved in the cloud.

Nix wrote:

...., so in real time you can't even give it any single, even the simplest, simplest, single command....

.
You can. On a smartphone, connected to the cloud (you quoted this yourself below I think from the instructions).

Nix wrote:

....
... In addition ( or perhaps above all) there are so many generalities and vague, non-specific, imprecise and misleading data in the Polish conrad "manual" that your head hurts " ...

.
Because it is a compilation of German, Polish and marketing language

Nix wrote:

....
For example, conrad writes:
- "Homematic IP - the next generation of the smart home". - this suggests that it is a development of older smart home systems, yet ...

HMIP is a development of earlier systems.
It used to be that CCU3 only supported HMIP and CCU2 only supported HM. Since a few years (4-6?) they have combined the software in the CCU, while the AP in the HMIP is a "novelty" allowing a simpler configuration for small, simple setups (e.g. only sockets, e.g. only heads, e.g. only lighting) because in total in such simple setups the CCU3 would be redundant.
Other than that (this is just my opinion) I think the AP is a response to market demand.

Nix wrote:

....
A system with AP should not be called a smart home at all,

.
.
Well... People who use the phrase "smart home" (in reference to "automated home") I usually ask where they got their intelligence - that's by the way .
In response, one of them wrote me that I can turn the Vistula back with this stick . Well ... I'll be turning it back and the marketing gibberish about the "intelligence" of the automatic home doesn't apply to me.

Nix wrote:

....
- "The access point connects your smartphone via the Homematic IP cloud to all Homematic IP devices and sends configuration data and app control commands to all Homematic IP devices. With Homematic IP, you can simply adapt your air conditioning solution to
your personal needs anywhere, anytime."

-Also a misleading description, because what's the point of the system connecting your smartphone to all your devices if you can't control them anymore?

.
Did I write it somewhere that it can't be done (if so, I apologise) or did you read it somewhere in the manual? Well, it can be done. The app on your smartphone is not just a preview. You can control it. The prerequisite (since it is via the cloud) is a working internet connection.

Nix wrote:

....
If that is the case, then in this case it is a direct command issue, so in simple terms it is nevertheless the execution of a simple scene ?

.
Now I think I understand.

I wrote that it is not possible to create scenes. Maybe I should write "it is impossible to create automatic scenes". For me, control from a smartphone is one thing (I don't call it a scene), while a "scene" is a record of some automatic action carried out when some event is detected. That to me is a scene (I guess that the marketing idea of calling it a :scene" came from the "actors" involved).

Nix wrote:

... I intend ... purchase both the "plain-old" heads and the new HmIP...

.

It will work. Two of my friends have this mix.

Due to the fact that with an HMIP thermostat you will not operate an HM head (and vice versa) it is better to use either HM or HMIP within one room.

Of course, if the light switch is not to have anything to do with the head (with heating) then the lighting can be done on HM and the head can be HMIP even within one room. However, if one window sensor were to, for example, turn off the light and lower the temperature at the same time then it would be better to have everything in one version.

Nix wrote:

...Well it is known that there will be some error in the reading because the head is on the radiator and therefore directly on the heat source, but maybe it works like this ?

.

It might even work. But the problem is something else entirely - temperature stability. Measuring at the radiator will cause the head to say in a few minutes that it has reached the set temperature and it will turn off. Of course, "after a while" as the heat dissipates (or as the radiator stops radiating) the head will open again. This cycle will be repeated until the whole room is heated. The situation is different if the room thermostat is properly placed, i.e. at the opposite end of the room to the control head. Since radiators are often located under windows, a good place to put them is around the front door, but with one caveat. The thermostats should be placed out of reach of the sun.

In this arrangement, the inertia of the system will be high and therefore the temperature more stable.

I have observed this with friends who have fitted heads and then, seeing how the head works, bought thermostats.

Nix wrote:

...
You wrote above that

Quote:

.... with the HMIP thermostat you will not operate the HM head (and vice versa)...

.

But this only applies to the impossibility of direct connections between HM and HMiP actors - but I understand that this could work( actor connections) via connections to CCU 3? Only that such a solution will be a bit less "reliable" in the sense of reliability ? Please explain what are the disadvantages of such a mixed actor connection ?

.

Exactly in the case of linear parameters (e.g. temperature), writing a script to handle this can be cumbersome. Besides, I don't know how then to force the head not to pay attention to its own temperature but to the temperature "behind the script". In my opinion, the direct connection cannot be replaced by a script in this case.

Nix wrote:

...

And is it possible to connect a wall thermostat, e.g. of the type Homematic Wireless Thermostat HmIP-WTH-2

I do not really understand the question. I will answer it as I understood it: yes, you can, after all that is what they were made for .

Nix wrote:

...
or it may be

Wireless temperature and humidity sensor
EQ-3 HomeMatic 132095 HM-WDS40-TH-I-2 ?

There is no such sensor (I have others) and I have never tested it but.... it seems to me that it should work. You create a heating group and attach elements to it (direct connections are created). The group takes on the characteristics of the connected devices, so the group will be able to program the schedule (from the head) and the head should listen to the "foreign temperature sensor". I think this makes sense. I will test it in the near future.

[edit]
One thing I have checked - there is no place in the head to 'save' the temperature taken from the sensor via the script. Likewise there is no place to save the "window status" from the window sensor. This has to be done via the heating group - and the heating group internally creates the direct connections itself, so there remains a variant of the same hardware version (HM or HMIP).

Perhaps it would be possible to do this by creating virtual devices which would be part of the heating group, so that the teperature taken from the sensor could be stored in these virtual devices, but... this probably sounds cosmic and is so-called "higher school". When I find a moment I might test such a scenario.

gag70 wrote:

The lifetime of these smart devices is about 10 years. After that, the manufacturer does not support. Sometimes the manufacturer is no longer there because it has gone bankrupt or sold to a larger....

.

This is all true and it is good that the Colleague has written about it. Add to this black true scenario the technological obsolescence of equipment.

Following this line of thought, one should skip the HM version and buy the HMIP because the HM is undevelopable which the manufacturer explicitly admits.

Nevertheless, at my place there are 95 HM devices and only 31 HMIP devices.

Finally: any such action (automation) is asking for trouble. It simply increases the failure rate of the system, because what could possibly go wrong with a simple two-pole switch? In automation, on the other hand, a lot can go wrong.

The final element: the heroes of the house enjoy (that's me) leaving behind a legacy that no one else will know how to maintain and service.

I did not fully understand what the colleague wrote therefore I will answer as I understood.

Nix wrote:

Well, but aren't the Homematic components ( old, without IP) already about 10 years old as of today...

.
Technologically how many they have. I don't know if 10 or less but I don't think new products offered by a manufacturer are 10 years old - well, unless in the technological sense.

Nix wrote:

.... and they are still being supported and by a new panel because the CCU3 is new after all ?

.

Hmm... it depends which HM support (without IP) you are talking about but the one that is less noticeable is:

- fewer and fewer new components.
- infrequent or no component firmware updates

While it is true that these components are still supported by CCU3.

Nix wrote:

...do you also have to make a program for the "basic" operation of smoke detectors, or will they, in the event of smoke detection, give an acoustic signal by themselves, and only e.g. the notification has to be programmed ?

.
Exactly as you wrote.

Nix wrote:

... Homematic's WebUI is, for me, however, a bit lacking in clarity and rather unintuitive....

.
E... there
In a "little while" everything will be clear.

Nix wrote:

...
How to make such a schedule more simply?

.

Go to -> Settings > Devices
Here, locate the head or heating group in which the head is located and press SET