Originally posted by: <email address deleted>
Hi,
a quick question, I've noticed there appears to exist a FHT-80B II
thermostat. The only thing I find on the internet that uses the name
"FHT-80B II" is a set from Conrad that exists out of a regular FHT-80B
and regulator for the radiator.
Now I would like to know what I have to buy to allow FHEM to meassure
the actual meassured temperature ? Is that possible with the FHT-80B
(Conrad article nr 750404 - 89) ? Or is there some other device I
need to buy ?
I noticed some discussions that talk about the "IST" temperature...
according to the Conrad manual, the comfort temperature is displayed,
not the actual meassured temperature (I'm assuming this is the "IST"
temperature). Or is there some smart setting that can activate this
when desired ?
As I said, I would like FHEM to be able to log the actual (IST)
temperature...
Any help for me ?
Kind regards,
Dave.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users on Linux" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~-
Originally posted by: <email address deleted>
Hi Dave,
If you only need only to log the current temperatur and maybe
humidity, I would recommend to purchase the
"Funk-Temperatur-/Luftfeuchteaußensensor S 300 TH" from ELV (http://
www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=2 0690)
Maybe Conrad has also a compatible model.
CUL is able to decode the format and FHEM will be able to show/log the
sensor data.
FHT-80B II has the same functionality as FHT-80B plus the ability to
show the current temperature on the display.
If you have already FHZ-1000PC/FHZ-1300PC and do also control your
heating radiators with FHT80B, so FHEM will be able to show the
measured temperature also. You will not need FHT80B II for that.
Hope, this helps.
cu
Maz
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users on Linux" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~-
Originally posted by: <email address deleted>
Dave schrieb:
> a quick question, I've noticed there appears to exist a FHT-80B II
> thermostat. The only thing I find on the internet that uses the name
> "FHT-80B II" is a set from Conrad that exists out of a regular FHT-80B
> and regulator for the radiator.
Right.
> Now I would like to know what I have to buy to allow FHEM to meassure
> the actual meassured temperature ? Is that possible with the FHT-80B
> (Conrad article nr 750404 - 89) ? Or is there some other device I
> need to buy ?
>
> I noticed some discussions that talk about the "IST" temperature...
> according to the Conrad manual, the comfort temperature is displayed,
> not the actual meassured temperature (I'm assuming this is the "IST"
> temperature). Or is there some smart setting that can activate this
> when desired ?
>
> As I said, I would like FHEM to be able to log the actual (IST)
> temperature...
You guessed right, that "Ist-Temperatur" ("Ist" in german = "is" in
english) is the currently measured temperature (as opposed to
"Soll-Temperatur" - "soll" = "should").
Anyway, yes, fhem can handle the FHT80b, however, since the fht80b is a
wireless device (and doesn't have a serial port or anything like that),
you will also need either a CUL device from busware or an FHZ1000PC or
FHZ1300PC (where the later one can also receive data from some
additional devices like the KS300 weather station).
Personally, I use a FHZ1300PC which controls our FS20 devices (wireless
switches and dimmers, roller blinds), the FHT stuff (controlling our
heating) and HMS100 (fire detectors, temperature and humidity monitors)
and our KS333 (or something) weather station.
In theory at least, the CUL device is not only the cheapest option, but
also the most versatile, able to monitor/control even more devices than
the FHZ1300PC, however, I'm not 100% sure wether the firmware is stable
yet (it is basically "just" a generic sender/receiver module for which
there is open-source firmware for its microcontroller, while the
FHZ1300PC is proprietary).
Regards,
Sven
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users on Linux" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~-
Originally posted by: <email address deleted>
On 28 Mai, 13:27, Sven Mueller wrote:
> Anyway, yes, fhem can handle the FHT80b, however, since the fht80b is a
> wireless device (and doesn't have a serial port or anything like that),
> you will also need either a CUL device from busware or an ...
As I own a CUL and some FHT80B, I know that the information above is
not fully correct.
FHT80B alone with CUL will not allow you to get the measured
temperature. You will also need a FHZ 1000 or FHZ 1x00PC and will be
able to snif the data exchanged between them.
But FHT80B's main purpose is to control the room temperature using the
radiator and is not usable as stand alone temperature sensor.
Best regards
Maz
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users on Linux" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~-
Originally posted by: <email address deleted>
Maz schrieb:
> On 28 Mai, 13:27, Sven Mueller wrote:
>> Anyway, yes, fhem can handle the FHT80b, however, since the fht80b is a
>> wireless device (and doesn't have a serial port or anything like that),
>> you will also need either a CUL device from busware or an ...
>
> As I own a CUL and some FHT80B, I know that the information above is
> not fully correct.
> FHT80B alone with CUL will not allow you to get the measured
> temperature. You will also need a FHZ 1000 or FHZ 1x00PC and will be
> able to snif the data exchanged between them.
I don't own a CUL, but am subscribed to the CUL-related google group. I
know they intend to get everything working that works with a FHZ1300
(and more), I'm just not sure how far they got yet. Especially wether
they got registration of FHT80Bs with CUL (instead of FHZ) working yet.
However, once an FHT80b thinks it successfully registered with an FHZ,
you don't need the FHZ any longer.
> But FHT80B's main purpose is to control the room temperature using the
> radiator and is not usable as stand alone temperature sensor.
Well, you _can_ use it as a pure temperature sensor with some tricks
(ie. you registered it with an FHZ, you gave it at least one motor, even
if just virtually).
But I would also suggest the HMS100T(F) for this purpose though, unless
you actually want to control your radiators with it, too.
regards,
Sven
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users on Linux" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~-
Originally posted by: <email address deleted>
Thanks all for the feedback so far. I'll try to describe more clearly
what I would like to do :
In order of importance:
- system needs to be built as such that it continues to work even with
pc or web server offline (according to its last known time table etc).
- have wireless thermostats in every room, that can be controlled both
locally and remotely
- measure temperature and preferably also humidity and display this on
drawing (of house and individual rooms) on web server (with
possibility to access thermostat time table per room)
- steer ventilation system based on humidity and temperature readings,
which includes not only inner readings of temperature and humidity,
but also outdoor reading of temperature and humidity. The ventilation
system only has 4 settings : off, speed 1, speed 2 , speed 3 (which
can be triggered by relays (potential free of course)).
- far more complex, but would be really cool to achieve: I'll be
buying a home security alarm very soon, placed by professionals
(needed by inssurance). It is a Siemens alarm (don't remember exact
type right now), and it appears to endorse X10 of some kind (and
possibly also simple serial communication) via optional module. Since
there will be magnetic triggers on every window, I would like to have
both systems communicate with each other in a sense that the security
system indicates which window is open, contradictory to Conrad
wireless system to detect open doors and windows. I kind of hope to
place FHEM in the middle to interpret security signals.
It is of course clear that systems only endorsed by communication
through pc and FHEM won't of course work when the pc is offline for
some reason, but at that point, each separate system should be capable
to continue to work individually : alarm on its own, heating on its
own, no need to take open window into account for heating at that
moment.
Now to get back to that heating :
with home automation in the back of my mind, I foresaw additional
valves (like a regular radiator) at junctions where the warm water for
the heating system is distributed. I have the choice here :
- I can buy conrad motorised valve, but that is battery operated...
for some reason I don't really like that, would have felt better with
an option to provide via 230V net.
- I can buy a motorised valve, steered by wireless conrad receiver,
both operate at 230V
This means that every radiator will continue to have its separate
thermostatic valve in each room, and that the motorised steering
system will be somewhere else (at the junctions of the warm water
system). I'm not sure if I am able to make this understandable. I'm
also not sure if this has advantages or disadvantages... the conrad
system is designed to have its motorised valve placed directly on the
radiator, what I foresaw is not even needed.
I'm wondering which is best for the valves... your advice is very
welcome !
Anybody an idea how long the lifespan is of such a heating system ?
Kind regards,
Dave.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users on Linux" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~-
> I'm wondering which is best for the valves... your advice is very
> welcome !
I only known the FHT family. My opinion:
- the battery is not a problem for me, I replace them once every 2
years, and this takes 5 min per room. If the battery is low, you get
an audible warning from the valves and a (fhem) message for the FHT80b
(not for the valves, as the 80b -> 8v communication is uni-
directional).
- the FHZ<->FHT communication is quite verbose, In my opinion this
will be a problem if you have a large number (10+?) of FHT's
- You cannot modify the way (hysteresis?) the valves are controlled by
the FHT.
- You cannot integrate humidity parameters without an external
controller like fhem. And if you are using fhem, you have to take into
account, that sending a large number (10/hour) of messages to the FHT
from fhem is error-prone due to the FHZ<->FHT communication.
> Anybody an idea how long the lifespan is of such a heating system ?
Good point. In my case it is more than 3 years.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users on Linux" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~-
Hi Dave,
to run FHEM in the center of your system a NAS device maybe a solution
for you.
Plug a FHZ and the X10-enabled Alarm via USB to a NAS, put FHEM on it,
and figure out how to deal with the alarm-system in FHEM.
As the NAS brings Web-Server, logging, and more nice features with it,
you have all in one place.
And as the NAS is taking quite little power, this could be a good
solution for 24/7 operation.
Beyond that, you need a running FHEM device, in order to have a
continuous log of your data in any way.
If you are interested, just have a look to the commercial product idea
on the FHEM page.
Best regards,
Olaf
On 28 Mai, 11:32, Dave wrote:
> Hi,
>
> a quick question, I've noticed there appears to exist a FHT-80B II
> thermostat. The only thing I find on the internet that uses the name
> "FHT-80B II" is a set from Conrad that exists out of a regular FHT-80B
> and regulator for the radiator.
>
> Now I would like to know what I have to buy to allow FHEM to meassure
> the actual meassured temperature ? Is that possible with the FHT-80B
> (Conrad article nr 750404 - 89) ? Or is there some other device I
> need to buy ?
>
> I noticed some discussions that talk about the "IST" temperature...
> according to the Conrad manual, the comfort temperature is displayed,
> not the actual meassured temperature (I'm assuming this is the "IST"
> temperature). Or is there some smart setting that can activate this
> when desired ?
>
> As I said, I would like FHEM to be able to log the actual (IST)
> temperature...
>
> Any help for me ?
>
> Kind regards,
>
> Dave.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users on Linux" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~-
Originally posted by: <email address deleted>
Dear all,
many thanks for the good advice. It seems like I can go ahead with a
conrad set. Actual temperature will be logged, etc... and I can
perfectly use the motorised valves from Conrad as well. I guess I can
place those anywhere I want (seen the odd way I engineered my piping
system).
FHEM is capable of gestioning all, so I guess it's up to buying the
right hardware now.
If you know a cheaper place to buy sets, don't hesitate to let me
know...
Kind regards,
Dave.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users on Linux" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~-
Originally posted by: <email address deleted>
Hi everybody again,
I checked out the ELV website, and the availability of FS20 devices
seems to be massive compared to Conrad ! A lot more possibilities, I
didn't even know about ... and all this is also possible with FHEM ?
I noticed IR controllers, 1-10V dimmers, audio controllers...
unbelievable !!! Especially that IR controller and 1-10V dimmer is
interesting for my home application (suddenly thrilled like a little
boy seeing toys) !!!
Two questions though :
- I noticed there are also (cheaper) thermostats from the brand "REV",
including FHT80B-like and motorised valved from REV. It appears they
are compatible with FS20 ? Will they also be usable for the "IST" or
actual temperature ?
- There is a weather station called WS 300, which uses the same
frequency as FS20. Are they compatible ? Can it be accessed through
FHZ1300 and FHEM ?
Many thanks (getting very excited from the goodies and toys),
Dave.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users on Linux" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~-
Originally posted by: <email address deleted>
Hi,
Dave:
> - There is a weather station called WS 300, which uses the same
> frequency as FS20. Are they compatible ? Can it be accessed through
> FHZ1300 and FHEM ?
>
The WS300 is just a fancy display. I don't know (and don't care) about
FHZ; you can use a CUL device to receive the data from the external
sensors.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
v4sw7$Yhw6+8ln7ma7u7L!wl7DUi2e6t3TMWb8HAGen6g3a4s6Mr1p-3/-6 hackerkey.com
- -
If two people love each other, there can be no happy end to it.
-- Ernest Hemingway
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users on Linux" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~-
> - I noticed there are also (cheaper) thermostats from the brand "REV",
> including FHT80B-like and motorised valved from REV. It appears they
> are compatible with FS20 ? Will they also be usable for the "IST" or
> actual temperature ?
Never seen them. Would be interesting to know if they are the remakes
of the FHT80b or the FHT8b (the latter is not being able to talk the
the FHZ).
> - There is a weather station called WS 300, which uses the same
> frequency as FS20. Are they compatible ? Can it be accessed through
> FHZ1300 and FHEM ?
You can access the WS300 through fhem. Through the WS300 fhem can
receive the signals of the WS300 family. The FHZ1300 accepts only the
messages of the KS300 from this family. CUL is not a real WS300
replacement: although it can receive messages from all family members,
it does not have a builtin temperature and a pressure sensor (or a
nice display).
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users on Linux" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~-
Originally posted by: <email address deleted>
Rudolf Koenig schrieb:
>> - I noticed there are also (cheaper) thermostats from the brand "REV",
>> including FHT80B-like and motorised valved from REV. It appears they
>> are compatible with FS20 ? Will they also be usable for the "IST" or
>> actual temperature ?
>
> Never seen them. Would be interesting to know if they are the remakes
> of the FHT80b or the FHT8b (the latter is not being able to talk the
> the FHZ).
REV thermostats are - to the best of my knowledge - relabeled FHT8b and
thus not capable of talking to an FHZ or fhem. Their motor units (the
actuactors that is) work quite fine with ELV/Conrad FHT80Bs though.
regards,
Sven
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users on Linux" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~-
Rudolf Koenig wrote:
> - the FHZ<->FHT communication is quite verbose, In my opinion this
> will be a problem if you have a large number (10+?) of FHT's
> - You cannot integrate humidity parameters without an external
> controller like fhem. And if you are using fhem, you have to take into
> account, that sending a large number (10/hour) of messages to the FHT
> from fhem is error-prone due to the FHZ<->FHT communication.
I use 9 FHTs in my house and it is impossible to set the day/night
schedules in one go, even for one FHT at a time, some on/off-times are
missed by the FHT. This is true even if the softbuffer is on. I consider
an extension of the FHT.pm module: if a new attribute "lazy" ist set,
one of the commands
mon-from1 mon-to1 mon-from2 mon-to2
tue-from1 tue-to1 tue-from2 tue-to2
wed-from1 wed-to1 wed-from2 wed-to2
thu-from1 thu-to1 thu-from2 thu-to2
fri-from1 fri-to1 fri-from2 fri-to2
sat-from1 sat-to1 sat-from2 sat-to2
sun-from1 sun-to1 sun-from2 sun-to2
will only be sent if it would actually change the setting.
What do you think?
Boris
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users on Linux" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~-
> I use 9 FHTs in my house and it is impossible to set the day/night
> schedules in one go, even for one FHT at a time, some on/off-times are
> missed by the FHT.
Management summary: I can prove your problem :-).
Datails (for the technically inclined, not for manager):
The FHZ1300 has a 74 byte FHT buffer, and if I remember correctly, the
FHZ1000 has 41. If you send FHT commands, then a slot in the buffer
will be allocated, you can verify this with "get FHZ fhtbuf". The size
of the slot depends: it is 5 bytes for the first FHT command, and two
further bytes for each "chained" command: "set wz day 7 hour 8 minute
9" will occupy 5+2*2=9 bytes. Sending these commands separately occupy
3*5=15 bytes. Another aspect: only one slot is sent in one FHZ<->FHT
session, which takes place roughly every 2 minutes. The FHZ can send
messages, if the FHT is passive, and do not wants to report something
(temperature) by itself. 8 is the maximum number of chained messages
for the FHZ. Strangely, if the communication aborts (which happens
quite often), then further slots in the buffer are allocated, I am not
sure what happens if the buffer is full and the communication aborts.
culfw@CUL has 48 bytes of buffer, and it has a similar allocation
scheme, _BUT_ it merges separate commands for the same FHT into one
slot. A command entry in the slot is deleted, if the command was
repeated by the FHT. This is not optimal, as the FHT only accepts a
command, when the final ack (for the whole chain) was sent. The CUL
command chain is only limited by the buffer size, I have not yet
verified if the FHT can accept more than 8. Note: the CUL does not
(yet) has the softbuffer support in fhem.
The 1% limit is reached with ca 540 RF messages per hour (ca 180 FS20
commands), a communication (FHZ->FHT) costs 4+#commands RF messages
for the FHZ. Sending the 28 daily on/off times for one FHT cost 140 RF
messages (and over an hour) if they are sent one-by one (or 44 / 10min
if using chained commands). Each FHT reports the temperature 4 times
per hour, each report "costs" the FHZ 6 RF messages, adding it up to
40% of the allowed airtime for 9 FHT's. If the communication is not
perfect, then the number is bigger due to resends. Due to the 1% limit
it takes theoretically more than an hour to update the 9 FHT's
(everything best case), but a lot can go wrong. I don't know if the
FHZ queues or drops FHT commands due to the 1% limit, the CUL drops
them.
> an extension of the FHT.pm module: if a new attribute "lazy" ist set,
> one of the commands
[...]
> will only be sent if it would actually change the setting.
>
> What do you think?
Go ahead!
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users on Linux" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~-
Am Sonntag, 7. Juni 2009 schrieb Rudolf Koenig:
> > an extension of the FHT.pm module: if a new attribute "lazy" ist set,
> > one of the commands
>
> [...]
>
> > will only be sent if it would actually change the setting.
> >
> > What do you think?
>
> Go ahead!
I just started to implement this when I saw that for nearly all of my FHTs
most readings are missing or have their initial values or they are from
2009-06-01, the last update of the fhem code from CVS.
list 1.wz.hzg
Internals:
CODE xxxx
DEF xxxx
IODev FHZ
NAME 1.wz.hzg
NR 39
STATE measured-temp: 23.3 (Celsius)
TYPE FHT
Readings:
2009-06-07 18:48:58 ack 0
2009-06-07 18:48:56 actuator 6%
2009-06-07 18:48:57 desired-temp 20.0
2009-06-07 18:48:58 end-xmit 0
2009-06-07 18:48:57 measured-high 0 <<<<
2009-06-07 18:48:57 measured-low 233 <<<<
2009-06-07 18:48:57 measured-temp 23.3 (Celsius)
2009-06-07 18:48:58 warnings none
from/to-values are missing! <<<<
=> only desired-temp, measured-temp and actuator have (meaningful) values.
Is this my personal problem or is there something wrong with previous week's
CVS version?
Boris
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users on Linux" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~-
> => only desired-temp, measured-temp and actuator have (meaningful) values.
>
> Is this my personal problem or is there something wrong with previous week's
> CVS version?
The last version removes all FHZ: elements from the STATE array (else
you would have each entry twice). I hope it does not brake something
else.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users on Linux" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~-
Rudolf Koenig wrote:
>> => only desired-temp, measured-temp and actuator have (meaningful) values.
>>
>> Is this my personal problem or is there something wrong with previous week's
>> CVS version?
>
> The last version removes all FHZ: elements from the STATE array (else
> you would have each entry twice). I hope it does not brake something
> else.
I revoke and state the contrary. I get all values, so it keeps on
working. It appears that my FHTs are not verbose enough - seems to
depend on the weather or so. An explicit refreshvalues makes the values
appear. No idea why it did not work yesterday...
Boris
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users on Linux" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~-
Am Sonntag, 7. Juni 2009 schrieb Rudolf Koenig:
> > I use 9 FHTs in my house and it is impossible to set the day/night
> > schedules in one go, even for one FHT at a time, some on/off-times are
> > missed by the FHT.
>
> > an extension of the FHT.pm module: if a new attribute "lazy" ist set,
> > one of the commands
>
> [...]
>
> > will only be sent if it would actually change the setting.
> >
> > What do you think?
>
> Go ahead!
changes made, tested, documentation updated, committed to CVS.
If the lazy attribute is set, FHEM won't send commands to the FHT if the
current reading and the value to be set are already identical. This may help
avoiding conflicts with the max-1%-time-on-air rule in large installations.
Not set per default.
Notabene: as opposed to the initial intention, lazy even applies to any FHT
command and not only to the *-from/-to commands.
Boris
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users on Linux" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~-