MQTT interval settings

Moderators: grovkillen, Stuntteam, TD-er

Post Reply
Message
Author
GravityRZ
Normal user
Posts: 206
Joined: 23 Dec 2019, 21:24

MQTT interval settings

#1 Post by GravityRZ » 23 Mar 2020, 20:06

i see MQTT interval settings in 2 different places

under
MQTT controller
Controller Queue
Minimum Send Interval: 100[ms]

under
Controller Settings
MQTT Retain Msg:
Message Interval: 100[ms]


what is the difference?
is this interval also used when using rules?

TD-er
Core team member
Posts: 8643
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: MQTT interval settings

#2 Post by TD-er » 24 Mar 2020, 00:35

For explanation on these parameters, please have a look at their documentation: https://espeasy.readthedocs.io/en/lates ... parameters

GravityRZ
Normal user
Posts: 206
Joined: 23 Dec 2019, 21:24

Re: MQTT interval settings

#3 Post by GravityRZ » 24 Mar 2020, 11:59

offcourse i first checked the manuals and documentation :-)


Minimum send interval is in the docs, message interval is not.

it looks like it is the same setting but you can change it on 2 different locations(controller settings and advanced settings)

i changed controller setting to 200ms and left the andvanced setting to 100ms

i see different behaviour in the timing between messages (sometimes 100ms sometimes 200ms)
it looks like the last one being modified is used

TD-er
Core team member
Posts: 8643
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: MQTT interval settings

#4 Post by TD-er » 24 Mar 2020, 13:56

Oh that setting Settings.MessageDelay

It is a left over from before the controller queue mechanism.
It looks like it is only used in:
- Controller Plugin 012: Blynk HTTP
- Controller Plugin 015: Blynk

It can be set using the command "messagedelay"

I think it should be removed as controllers now have their own minimal send interval option which is essentially what should be used.

GravityRZ
Normal user
Posts: 206
Joined: 23 Dec 2019, 21:24

Re: MQTT interval settings

#5 Post by GravityRZ » 24 Mar 2020, 17:23

check, Thanks.

i am doing some tests with the delays to see if the pulsecounter can react more accurately.
i suspect that the 100ms delay is sometimes causing dropped messages or repeated messages.

when lowering the delay to 10ms i got instantly more pulses(probably messages which were send out more than once)
when raising the delay to 200ms it is running 24 hours now without any missed or extra pulses

this is strange because the pulsecounter on the esp are exactly the same as the one in domoticz
e.g. sending out less/more messages is not the issue otherwise there would be a difference in both counters

get back when i have found the problem

TD-er
Core team member
Posts: 8643
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: MQTT interval settings

#6 Post by TD-er » 24 Mar 2020, 21:04

Please be aware that you probably can only send out messages per WiFi beacon interval. (102.4 msec)
So sending a message with smaller interval will lead to a longer message queue.
The MQTT client does handle queues a bit, so it is possible more than a single message can be flushed at once, but still that's roughly the upper limit of how many messages can be sent via WiFi.

GravityRZ
Normal user
Posts: 206
Joined: 23 Dec 2019, 21:24

Re: MQTT interval settings

#7 Post by GravityRZ » 24 Mar 2020, 21:46

good info.
it is not that i want to send out messages faster than 100ms but i think that once in a while this is the case thus causing lost or multiple packets

i have a temp sensor which sends out temp every 60 seconds
the pulsecounter triggers a rule which sends out 2 messages right after each other
once every 30 seconds a message will be send out also

so if 102ms is the fastest it can do then indeed this can cause problems when 2 or 3 messages are send at the same time.

sofar sogood with setting the delay to 200ms but if this still does not fix things i will send out the pulse over MQTT and the others over HTTP to see if this will fix things

thanks

TD-er
Core team member
Posts: 8643
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: MQTT interval settings

#8 Post by TD-er » 26 Mar 2020, 00:26

GravityRZ wrote: 24 Mar 2020, 21:46 [...]
so if 102ms is the fastest it can do then indeed this can cause problems when 2 or 3 messages are send at the same time.
[...]
Well it is still no problem as the messages will be put in a queue.
There will be a problem when you try to send roughly 10 messages per second, continuously.
Then the buffer will fill up as it can not cope with the needed rate.
The controller queue has a mechanism then to deal with a full queue by either ignore the new value or delete the oldest message. (user selectable)

Only thing is, some controllers do produce quite large messages which may need to be stored in full in the queue.
So a full buffer of queued messages may then use quite a big part of the available resources.

GravityRZ
Normal user
Posts: 206
Joined: 23 Dec 2019, 21:24

Re: MQTT interval settings

#9 Post by GravityRZ » 26 Mar 2020, 08:39

i do not think that the queue gets flooded because like i said i am sending out 1 message every 30 seconds, 1 message every 60 seconds and when the pulsecounter is counting max 2 messages together per 2 seconds.

my thoughts were when those messages once in a while are send out at the same time.
i checked and still no extra or missed messages
i changed the time interval to 200ms
i also might have changed the LWT settings and the will retain settings.
However i do not think this is causing the problem because when i was using http i had the same problem.
i switched to mqtt because it has less overhead but that did not change the problem

please note i use MQTT as a controller which is enabled but i only send out 1 message per 60 seconds(temp) through the controller.
The other messages are send out by using rules.
anyway still stable for 2 days now

if this will be stable for a week i can change the delay to see if this was indeed causing the problem. then we know what to look for.
mqttsettings.JPG
mqttsettings.JPG (63.2 KiB) Viewed 13638 times

TD-er
Core team member
Posts: 8643
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: MQTT interval settings

#10 Post by TD-er » 26 Mar 2020, 17:07

What exactly is the problem you're facing?

If the broker is online (not in local network) then you may need to have a look at the timeout setting.
For a local network, 200 msec may be OK, but for an online broker it may be a bit too short.

GravityRZ
Normal user
Posts: 206
Joined: 23 Dec 2019, 21:24

Re: MQTT interval settings

#11 Post by GravityRZ » 27 Mar 2020, 12:58

my MQTT broker is local and running as a mosquitto package on synology.

the behaviour i am facing is this

i use a pulsecounter to send out 1 pulse per liter for my watermeter
this pulse arrives in domoticz on a counter incremental
once synced every pulse detected should increment the watermeter in domoticz by 1
this works but i bnoticed that sometimes the counter in domoticz was ahead (sometimes 1, sometimes 2 or 3)
i thought this was because the pulse maybe jittered
i changed to MQTT but the behaviour stayed the same
the thing is the total amount of pulses detected was the same as the amount of pulses in domoticz but still the meter in domoticz was ahead
not logical. now increased the message delay to 200ms and it seems more stable

for over 2 days no extra or missing pulses
today i noticed i was missing a pulse but the amount in esp was ok but in domoticz it was missing 1(looks like a missing transmission but still logical)

i increased the delay to 250ms to see if it will be stable for longer than 2 days.

so behaviour at the moment is logical and everything points to missing MQTT message.
the first setup however puzzles me because it is not logical behaviour. MQTT can send out extra messages but http does not(to my knowledge)

i have put it in a sheet so it is better to understand what the problem was and what the problem is now
this behaviour is not instantly but happens somewhere during the day(not a fixed timeframe)

please note i send out the mqtt pulses by using rules
i send out mqtt by using the controller

mqtt timing.JPG
mqtt timing.JPG (52.96 KiB) Viewed 13533 times

TD-er
Core team member
Posts: 8643
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: MQTT interval settings

#12 Post by TD-er » 27 Mar 2020, 20:04

The only explanation I can think of for the extra count in Domoticz is when ESPEasy experiences a timeout and resend the message.
How are the pulse count values recorded in Domoticz? Do you just send out a message to notify "+1" or do you send the counter value? I assume the first.

GravityRZ
Normal user
Posts: 206
Joined: 23 Dec 2019, 21:24

Re: MQTT interval settings

#13 Post by GravityRZ » 28 Mar 2020, 09:22

yes, i only send +1 to an incremental counter.
That counter also shows the daily usage.

so i can check the real meter value against the domoticz meter value and i check the total counts is esp(gets reset at 00:00) against the daily usage on the domoticz meter.
both numbers need to be the same, which they are lately except for what looks like a lost pulse or an extra pulse.

i increased message interval to 250ms and timeout to 300ms.

how can the esp experience a timeout? it can not know if the send out value is received or not.
The esp unit is +/- 1 meter way from my router so wifi signal should not be an issue.
the esp is also set to force wifi no sleep
Last edited by GravityRZ on 28 Mar 2020, 09:37, edited 1 time in total.

TD-er
Core team member
Posts: 8643
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: MQTT interval settings

#14 Post by TD-er » 28 Mar 2020, 09:35

The MQTT client, WiFi code and IP-stack code is doing a lot of checks.
I have to look into the pubsubclient code to be sure, but I guess even there is some feedback whether a MQTT message is accepted by the broker.
If that acknowledgement is lost, then the MQTT client code can decide to send it again as it has its own buffer.

Apart from that, there is always the highly theoretical hypothesis that there might be a bug in the ESPEasy code, but that still has to be proven :)

GravityRZ
Normal user
Posts: 206
Joined: 23 Dec 2019, 21:24

Re: MQTT interval settings

#15 Post by GravityRZ » 28 Mar 2020, 09:42

with http i experiencd the same problems(most of the time extra pulses instead of missing pulses) so it looks like it has nothing to do with the protocol
now with MQTT i experience more logical things, if i miss a pulse i can see that(because it was counted inside the esp but not in domoticz)

maybe a combination of problems

anyway testing it again to see if it improves

should clean sessions make a difference(i think this will take more overhead thus the problem might get bigger)

TD-er
Core team member
Posts: 8643
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: MQTT interval settings

#16 Post by TD-er » 28 Mar 2020, 09:59

Nope a clean session will very likely not make a difference here.
ESPEasy does have some logic for all controllers where it checks if sending was successful.
If not, then it will retry the same message later.
It can be unsuccessful if it detects to be offline, or when it is set to wait for an acknowledgement which is not received. (and probably a few more)


Only thing that may happen with increasing timeout or delay is that you may put a limit on the number of pulses sent per second.
But "100" pulses in a day doesn't sound like much, so that will unlikely to be an issue here.

What also may happen when monitoring some meters is that the detection wheel (for water meters for example) is placed such that it may count extra values.
But that should also be shown in the ESPEasy counter and not make a difference between the Domoticz count and ESPEasy count.

GravityRZ
Normal user
Posts: 206
Joined: 23 Dec 2019, 21:24

Re: MQTT interval settings

#17 Post by GravityRZ » 28 Mar 2020, 21:00

still testing with the 250ms interval settings and 300ms timeout setting.

i took a shower which is taking approx 12 liters a minute (5 seconds between pulse)

i noticed that despite the 250ms interval setting the time between messages when they arrive at domoticz is not 250ms but 200ms or sometimes even 100ms
can you explain this? It looks like the interval setting is not or not always used

idx 337 is the pulsecounter and idx 338 the waterflow which are send out at the same time using rules
idx339 is the temp sensor on the same esp but is send out every minute

Code: Select all

2020-03-28 19:55:02.453  MQTT: Topic: domoticz/in, Message: {"idx":337,"nvalue":0,"svalue":"1"}
2020-03-28 19:55:02.574  MQTT: Topic: domoticz/in, Message: {"idx":338,"nvalue":0,"svalue":"0.0"}

2020-03-28 19:55:10.456  MQTT: Topic: domoticz/in, Message: {"idx":337,"nvalue":0,"svalue":"1"}
2020-03-28 19:55:10.574  MQTT: Topic: domoticz/in, Message: {"idx":338,"nvalue":0,"svalue":"7.8"}

2020-03-28 19:55:17.428  MQTT: Topic: domoticz/in, Message: {"idx":337,"nvalue":0,"svalue":"1"}
2020-03-28 19:55:17.522  (Aeonlabs Z-wave stick Gen5) Usage (Watt Tuinlampen)
2020-03-28 19:55:17.526  (Aeonlabs Z-wave stick Gen5) General/kWh (kWh Tuinlampen)
2020-03-28 19:55:17.632  MQTT: Topic: domoticz/in, Message: {"idx":338,"nvalue":0,"svalue":"8.2"}

2020-03-28 19:55:25.431  MQTT: Topic: domoticz/in, Message: {"idx":337,"nvalue":0,"svalue":"1"}
2020-03-28 19:55:25.613  MQTT: Topic: domoticz/in, Message: {"idx":338,"nvalue":0,"svalue":"8.3"}
2020-03-28 19:55:30.538  (RFXtrx433XL) Temp + Humidity (Woonkamer)
2020-03-28 19:55:31.427  MQTT: Topic: domoticz/in, Message: {"idx":337,"nvalue":0,"svalue":"1"}
2020-03-28 19:55:31.563  (Aeonlabs Z-wave stick Gen5) Usage (Watt Tuinlampen)
2020-03-28 19:55:31.567  (Aeonlabs Z-wave stick Gen5) General/kWh (kWh Tuinlampen)
2020-03-28 19:55:31.664  MQTT: Topic: domoticz/in, Message: {"idx":338,"nvalue":0,"svalue":"9.1"}

2020-03-28 19:55:38.454  MQTT: Topic: domoticz/in, Message: {"idx":337,"nvalue":0,"svalue":"1"}
2020-03-28 19:55:38.575  MQTT: Topic: domoticz/in, Message: {"idx":338,"nvalue":0,"svalue":"9.2"}
2020-03-28 19:55:40.504  MQTT: Topic: domoticz/in, Message: {"idx":338,"nvalue":0,"svalue":"9.2"}

2020-03-28 19:55:44.451  MQTT: Topic: domoticz/in, Message: {"idx":337,"nvalue":0,"svalue":"1"}
2020-03-28 19:55:44.572  MQTT: Topic: domoticz/in, Message: {"idx":338,"nvalue":0,"svalue":"9.6"}

2020-03-28 19:55:50.454  MQTT: Topic: domoticz/in, Message: {"idx":337,"nvalue":0,"svalue":"1"}
2020-03-28 19:55:50.575  MQTT: Topic: domoticz/in, Message: {"idx":338,"nvalue":0,"svalue":"10.0"}
2020-03-28 19:55:51.894  MQTT: Topic: domoticz/in, Message: {"idx":339,"RSSI":10,"nvalue":0,"svalue":"19.9"}

2020-03-28 19:59:11.422  MQTT: Topic: domoticz/in, Message: {"idx":337,"nvalue":0,"svalue":"1"}
2020-03-28 19:59:11.609  MQTT: Topic: domoticz/in, Message: {"idx":338,"nvalue":0,"svalue":"11.7"}

2020-03-28 19:59:16.455  MQTT: Topic: domoticz/in, Message: {"idx":337,"nvalue":0,"svalue":"1"}
2020-03-28 19:59:16.570  MQTT: Topic: domoticz/in, Message: {"idx":338,"nvalue":0,"svalue":"11.7"}
2020-03-28 19:59:17.232  (Aeonlabs Z-wave stick Gen5) Usage (Watt Tuinlampen)
2020-03-28 19:59:17.236  (Aeonlabs Z-wave stick Gen5) General/kWh (kWh Tuinlampen)
2020-03-28 19:59:17.499  MQTT: Topic: domoticz/in, Message: {"idx":338,"nvalue":0,"svalue":"11.7"}

2020-03-28 19:59:21.445  MQTT: Topic: domoticz/in, Message: {"idx":337,"nvalue":0,"svalue":"1"}
2020-03-28 19:59:21.609  MQTT: Topic: domoticz/in, Message: {"idx":338,"nvalue":0,"svalue":"12.0"}

TD-er
Core team member
Posts: 8643
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: MQTT interval settings

#18 Post by TD-er » 28 Mar 2020, 21:32

I guess that the "interval settings" you refer to are the controller's "Minimum Send Interval" ?
This is the (minimum) time between calling the publish command.
If for some reason somewhere on the line a delay occurs, then the time between arrival on the Domoticz server may be less than that minimum.

Delays can occur at:
- During flushing the buffer of the PubSubClient (it can hold upto 1 kB of messages)
- WiFi data is only sent every 102.4 msec (Access point beacon interval on most access points)
- Processing time on the broker. Maybe the broker could not process the messages as it was waiting for some disk access or something else...
- Maybe the Domoticz service does only check for new messages every N msec. This can appear as if the send interval is halved.

So there are lots of places where a message can be delayed.
This may look like some messages appear to be sent with shorter interval than set in the controller.
But when you look at a larger set of messages, the total time to send those messages should be more than the minimum send interval per message.
In other words, on average the send interval should not be less than this set minimum.

GravityRZ
Normal user
Posts: 206
Joined: 23 Dec 2019, 21:24

Re: MQTT interval settings

#19 Post by GravityRZ » 29 Mar 2020, 20:59

ok thanks.

everything was totally stable for 3 days and and of a sudden 5 missed pulses.
i suspect that this problem might be related to wifi stablitity
this is easilly checked because the amount in the ESP is different then the one in domoticz.

Since the values in the ESP are now right i am going to change the rules
instead of sending out 1 pulse i am going to send out the complete value

this way the setup is not affected by either mqtt disruption or wifi dissruption(do not think this is an ESP problem)

i am doing a check on the counter
if it is zero(because of a cold reboot) i use a preset value
for warm reboots it will stay ok because the dummy counter is remembered

GravityRZ
Normal user
Posts: 206
Joined: 23 Dec 2019, 21:24

Re: MQTT interval settings

#20 Post by GravityRZ » 30 Mar 2020, 19:38

@TD-er

i discovered what looks like the root cause of the problem.
however the problem seems very strange.

i changed the rules so i can see what the total count is as well as the daily count on both ESP and in domoticz.
what looked like a MQTT or transmission problem actually seems to be a calcultation problem inside the ESP

to explain what i see.
i copy the dailytotal to a dummy device every time the pulsecounter is triggered
in that same rule i increment my total counter with 1 inside the the ESP
this value is send over.

i discovered that things were running perfectly in sync and all of a sudden i check my watermeter and it is 1 liter behind(both on the total as well as the daily usage
inside the ESP i check the values and see that the daily usage is 1 higher than domoticz
this means that when there is a pulse, the total from the pulsetrigger is incremented, copied to the dummy device but the total counter is NOT INCREMENTED

this is the piece of code i use
i suspect that once in a while the pulsecounter is counting the pulse(and updating it's own values) but is not triggering/running this rule thus missing a liter on the counter
how is this possible?

Code: Select all

On Watermeter#Count do						// When Pulse is detected
	if [Watermeter#Count] = 1 and [Watermeter#Time] > 2000	// send pulse only when Time is not to low to avoid jitter
		TaskValueSet 3,3,[Water#Counter]+1		// increase total counter with 1
		Publish domoticz/in,'{"idx":344,"nvalue":0,"svalue":"[Water#Counter]"}'
		TaskValueSet 3,1,60000/[Watermeter#Time]	// set Water#Flow
		TaskValueSet 3,4,[Watermeter#Total]		// copy Watermeter#Total to Water#LitersToday
		Publish domoticz/in,'{"idx":338,"nvalue":0,"svalue":"[Water#Flow]"}'
	endif
EndOn

watermeter fault.jpg
watermeter fault.jpg (96.41 KiB) Viewed 13332 times

User avatar
Ath
Normal user
Posts: 3417
Joined: 10 Jun 2018, 12:06
Location: NL

Re: MQTT interval settings

#21 Post by Ath » 30 Mar 2020, 19:56

Could this line
TaskValueSet 3,3,[Water#Counter]+1
be an issue in this script? As on the other lines you use [Watermeter#...] and [..#Count]... :?:
/Ton (PayPal.me)

GravityRZ
Normal user
Posts: 206
Joined: 23 Dec 2019, 21:24

Re: MQTT interval settings

#22 Post by GravityRZ » 30 Mar 2020, 20:09

thanks for checking. i can use all the help i can get..

here are the devices so you can see what i am using.

i have a pulsemeter called Watermeter and a dummy device called Water
so it looks like that rule is ok.

the reason for dummy device is i can not use the values from the pulsecounter direcly(maybee i should to avoid this problem but i do not know if i can set the total amount of the pulsecounter

devices2.JPG
devices2.JPG (72 KiB) Viewed 13324 times

TD-er
Core team member
Posts: 8643
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: MQTT interval settings

#23 Post by TD-er » 30 Mar 2020, 22:34

I'm looking at this line:

Code: Select all

	if [Watermeter#Count] = 1 and [Watermeter#Time] > 2000	// send pulse only when Time is not to low to avoid jitter
You do explicitly compare with = 1
What happens if the counter has seen 2 pulses? Or if the time is less than 2000?
Can you change the =1 into !=0 ?
If it counts 2 pulses between the PLUGIN_READ, then your rules will not count those.

GravityRZ
Normal user
Posts: 206
Joined: 23 Dec 2019, 21:24

Re: MQTT interval settings

#24 Post by GravityRZ » 31 Mar 2020, 09:25

ok i will try.
my pulsecounter is set at an interval of 1 second(so the counter resets every second)
the max pulses i get is around 1 pulse every 2.4 seconds(25 liters per second)
so to avoid jitter(which is also done with the debounce time) i only send a pulse if the time is greater than 2000ms(eg 30 liters per second)
everything faster means jitter so i like to skip that.

at the moment i send out the complete metervalue so that it is easier to see what is going wrong.

the only thing i can think of that the counter gets reset (because of the 1 second interval) at exactly the same time as a pulse is coming in.
The pulse is counted on the pulsecounter but skipped in the rules because it got reset instantly.
this would account for a missing pulse and this is why i would like to have a pulsecounters which only counts when a pulse is received instead of on an inteval base.

The reason why i have this problem(and others have not) is probably they al use old rules which counts pulses for 60 seconds and then send out the watermeter value and the flow value.
My functionality is instantly (well 1 second) but i think i am hitting the limits

TD-er
Core team member
Posts: 8643
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: MQTT interval settings

#25 Post by TD-er » 31 Mar 2020, 12:27

the only thing i can think of that the counter gets reset (because of the 1 second interval) at exactly the same time as a pulse is coming in.
That's a possibility and also not so unlikely as it may seem as it doesn't have to be that "exact"
There is some delay between actually processing the event in rules and scheduling the event, as there is a queue for events so processing a burst of events will not lock up the node.
Instead of fetching the value from the [taskname#varname], you can also check the event variables.
Those are stored in the event when it is created.

It is also possible the time between pulses is less than 2000 msec.
It may not seem like it when you consider the flow constant.
Think of what happens when you stop the water flow. That's rather abrupt and you often hear the water pipes make a clunking sound if the washing machine stops taking in water.
This 'shock wave' also ends up in the water meter, so it is possible the dial may actually move forward and back a bit.
This will result in 2 pulses with a very short interval, while the first one may actually be a valid one.
But as their interval is very short, it will be rejected. Also because you are looking at the last interval and not the interval as recorded when the event is created.
That may explain the missing pulses compared to the actual water consumption on the meter.

GravityRZ
Normal user
Posts: 206
Joined: 23 Dec 2019, 21:24

Re: MQTT interval settings

#26 Post by GravityRZ » 31 Mar 2020, 13:01

thanks.
i will try to narrow my search. eventually i will solve this thing :-)

i recognize the Clunk sound HaHa

how can i use the event variables and the interval recorded from the rules page.

i know i have read somewhere that there is a change between values recorded and values ehich are vissible on the plugin but forget where it was

TD-er
Core team member
Posts: 8643
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: MQTT interval settings

#27 Post by TD-er » 31 Mar 2020, 13:29

See the documentation on %eventvalue%
https://espeasy.readthedocs.io/en/lates ... nt-command

GravityRZ
Normal user
Posts: 206
Joined: 23 Dec 2019, 21:24

Re: MQTT interval settings

#28 Post by GravityRZ » 31 Mar 2020, 14:25

i have read it but still not clear.

Event,Multi=1,2,3,99

what is Multi? is it the name of the Task?

i have a pulsecounter called watermeter with Count, Total,Time
i also have a temp sensor with only trmperature.

i understand that you can trigger an event on a base that something is received but do not see how i can create an event which will trigger if either of the 3 values change(or one)
so i do not see how to relate EVENT to a specific device or a changed value of a device

can you give an example?

TD-er
Core team member
Posts: 8643
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: MQTT interval settings

#29 Post by TD-er » 31 Mar 2020, 15:15

Nope, that's the event name.
By sending the command

Code: Select all

event,bla=1,2,3,4
You can trigger it in the rules via:

Code: Select all

on bla do
...
So "Multi" in the example you have an event called "Multi" with %eventvalue1% = 1, %eventvalue2% = 2, etc.

You can also send an event (or let it send via a task) like "[taskname#taskvar]"

So the line starting with "Event," is just a command to send out an event.

GravityRZ
Normal user
Posts: 206
Joined: 23 Dec 2019, 21:24

Re: MQTT interval settings

#30 Post by GravityRZ » 31 Mar 2020, 16:00

maybe you are explaining something i am already doing because i still do not get it.

i get the explanation, i get your explanation

i do not get how this relates to my situation

i currently wait for Watermeter#count to change (this is an event right)
i then act on it by checking the value of watermeter#Count

you tell me to check the internal variable for this event(so the values as they are inside the ESP but not yet written to the task variables, how

Code: Select all

Instead of fetching the value from the [taskname#varname], you can also check the event variables.
Those are stored in the event when it is created.
do you mean
%value1% corresponds to Watermeter#Count (before in is written)
%value2% corresponds to Watermeter#Total (before in is written)
%value3% corresponds to Watermeter#Time (before in is written)

Post Reply

Who is online

Users browsing this forum: No registered users and 15 guests