ZG-005 4 channel relay zigbee board (power vs power1, pulsetime and ZbEndpointSuffix/SetOption101 in webui)

[ortegafernando]

Hi, I have use ZbEndpointSuffix/SetOption101 to be able to operate all of my 4 channel relay zigbee board.
(https://s.click.aliexpress.com/e/_DDK89o5)

I have several questions:

1. Is there any possibility of showing the state of the 4 relays in the webui? May be there is any other command that I need to configure?
2. Besides usual power, power2, power3 and power4 ...Is there any possibility to use also power1 to be as power ? As we could define power1 as alias of power
3. I can not use pulsetime, I understand that pulsetime doesn't work with zigbee relays. is the only wat to make this work to use special rules (recieve an special mqtt command to execute a rule)? Anyone has an example? (I am going to use it as irrigating system, and I like pulsetime because with usual power on and power off commands from my server there is a risk if the power off command "never arrives" so I waste lots of liters of water. With pulsetime the risk is lower, we only depend in tasmota, not in server, communication, ...)

Thanks a lot

[ortegafernando]

About question 3, may be we can discuss about these options. What do you think is it the best?

(pseudo code as "power1 on" and "power1 off" will be zigbee send commands: zbsend {"device":"XXXX","send":{"power":1}} and zbsend {"device":"XXXX","send":{"power":0}})

Option 1 (DELAY LIMIT OF 360 seconds)

backlog power1 ON; delay 600; power1 OFF

Option 2 (DELAY LIMIT OF 360 seconds.)

rule1
	on event#zbpulsetime1>0 do backlog power1 ON; delay %value%; power1 off endon
	on event#zbpulsetime1==0  do power1 off endon
rule1 1

And I send to zigbee gateway: "event zbpulsetime1=600" for 60 seconds

Option 3:

rule1
	on event#zbpulsetime1>0 do backlog power1 ON; ruleTimer1 %value% endon
	on rules#timer=1 do power1 OFF endon
	on event#zbpulsetime1==0  do backlog power1 OFF; ruleTimer1 0 endon
rule1 1

And I send to zigbee gateway: "event zbpulsetime1=20" for 20 minutes

(and make the same for all 4 relays)

[s-hadinger]

Option 1 is not good. You don't want to block the entire Tasmota for 10 minutes

Option 2 same, don't use delay for long periods

Option 3 looks better indeed. But keep in mind that if you restart your Tasmota device, the Off command is never sent. You might want something more robust, like sending an Off message anyways at regular intervals.

[ortegafernando]

Oh sorry, I misunderstood delay command. Of course the only good option is option 3.

About the restart of Tasmota, I think that I can configure a boot rule to power off ALL RELAYS, as there is no powerOnState in zigbee relays. What do you think of this solution? Thanks a lot for mention this matter.

[barbudor]

Actually don't use delay AT ALL
Beside blocking Tasmota for the duration of delay, it is also unreliable as Tasmota may decide to break the delay if another command is received

Use RuleTimers or Berry Timers

[sfromis]

While timers is indeed the right approach, the Delay command is not blocking, just unreliable. What is blocking is tasmota.delay() in Berry, which therefore should not be more than max 50 ms.

[s-hadinger]

Is there any possibility of showing the state of the 4 relays in the webui? May be there is any other command that I need to configure?

Not natively, but if your Zigbee Gateway is based on ESP32, it is now possible to add Berry scripting to enhance the Web UI (although not documented yet)

Besides usual power, power2, power3 and power4 ...Is there any possibility to use also power1 to be as power ? As we could define power1 as alias of power

Not sure what you mean here, why would it help to use power instead of power1?

[ortegafernando]

Hi, it is only to have an easier way of configure nodered and grafana. (just when I recieve powerX state, take last letter ("X") so you know with relay number is. If we dont have POWER1, that psuedo code is different).

It is not a big problem, but it is pitty. I will fight with power, power2, power3 and power4.

[sfromis]

Another approach could be to configure fake relay pins, appearing like normal relays, and then use rules to bridge the on/off events to Zigbee. That could even work with the normal PulseTime. Or using Berry if running Tasmota on ESP32 instead of ESP8266.

[ortegafernando]

Thanks a lot @sfromis, I understand that this option 4 is more complicated, but it lets me to see relays' states in webui, doesnt it?

[sfromis]

It also does that. The point is that it works just like normal relays when you make sure to reflect the actions to Zigbee commands. Thus it will automatically work with tools working for regular power channels. It is actually less complicated than inventing new ways of making commands when involving MQTT-based tools already working with Tasmota.

However, if you want to keep in sync with the Zigbee relay switching for other reasons, you'll also have to pick up on the Zigbee messages about that, and take action as relevant. This is the only point where it starts to get complicated.

If using ESP32 and Berry, you do not even need to configure fake relay gpio pins to add "virtual" power channels for such use.

[ortegafernando]

However, if you want to keep in sync with the Zigbee relay switching for other reasons, you'll also have to pick up on the Zigbee messages about that, and take action as relevant. This is the only point where it starts to get complicated.

About this, you are saying about switching relays, for example, with the zigbee board's buttons, aren't you?

If using ESP32 and Berry, you do not even need to configure fake relay gpio pins to add "virtual" power channels for such use.

I have been using rules since years, but Berry it is totally new for me. Any discussion or issue to learn about this case? (I will search for Berry documentation, but may be you know about some piece of code to start with). Will it be also complicated about picking up zigbee messages?

thanks a lot.

[sfromis]

Yes, if the Zigbee device has buttons to cause relay state changes, that is included in "other reasons". There could be other ways too.

When it comes to Berry, first make sure that it is even available, which is only if your coordinator bridge running Tasmota has ESP32 instead of ESP8266.

What I specifically meant by "you do not even need to configure relay gpio pins" would be setting tasmota.global.devices_present each boot. After that, you have additional power channels acting just like normal relays all the way, including using them with "classic" rules.
https://tasmota.github.io/docs/Berry/#low-level-access-to-tasmota-globals-and-settings

Same docs page also has more general Berry info, including a bit of introduction.

To illustrate a strategy, here's a way of doing something very similar to a "classic" rule:

tasmota.add_rule('Power1#state',
  def (value,trigger,data)
    tasmota.cmd(f'ZbSend ..... {value} ....')
  end)

This reflects power channel 1 actions to commands. Sure, this does not look "better" than classic rules, but if you start doing "less simple" things, Berry is a full programming language instead of dealing with various tricks to craft rules, getting around the pretty limited options.

[ortegafernando]

Hello @sfromis

I am trying and I have read a lot. I think that I have discovered a little bit about you are saying, but I am not an expert. Even I have an strange error about "f'". Berry says that it is undeclared.

Any way: I have this working as an example (I have created 2 buttons in webui by using devices_present)

tasmota.global.devices_present = 2
import string
tasmota.remove_rule('Power2#state')
tasmota.add_rule('Power2#state',
  def (value,trigger,data)
	#print("value: ", value, " - trigger: ", trigger, " - data: ", data) 
	#print(string.format('zbSend {"device":"0x6a96","endpoint": 2, "send":{"power":%s}}', value))
        #print(f'zbSend {{"device":"0x6a96","endpoint": 2, "send":{{"power":{value}}}}}')
	tasmota.cmd(string.format('zbSend {"device":"0x6a96","endpoint": 2, "send":{"power":%s}}', value))
  end)

Is this the way are you saying? I think that I have understand what you mean, as if I write in console "pulsetime2 50" and then "power2 on" I get a "5-seconds-relay-ON-state". Your solution is great !

Do you think that I am on the right track?
Is it just to add 4 rules, one for each power option?
Of course, if I want, I need to also add rules in case I am clicking directly in 4 channel relay board's buttons (but in this case I have no idea of how to detect this with zbrecieved

Any help from any one is welcome. Thanks a lot.

[sfromis]

If that f is undeclared, you are probably using an older Tasmota version, and you have correctly identified that string.format is the similar story, just not as succinct. So yes, you seem to be on the right track.

When it comes to processing ZbReceived, you can again use triggers similar to what's available with "classic" rules and JSON-based triggers. With Berry a nice thing is that you get a map with all the fields, instead of the trigger only useful for picking up one. How to detect is by seeing patterns in the payload, where you'll probably find "useful data" indicating power state.

With a single-channel Zigbee relay module, I'm seeing "Power":1 in the payload. Beware that you may also see this field in payloads for other reasons than state change, if you care about that.

I can recommend using ZbName to assign readable alias names to the device(s), and use those. I'm never using those "short addresses" for anything, it is more useful to have a good name.

[ortegafernando]

When it comes to processing ZbReceived, you can again use triggers similar to what's available with "classic" rules and JSON-based triggers. With Berry a nice thing is that you get a map with all the fields, instead of the trigger only useful for picking up one. How to detect is by seeing patterns in the payload, where you'll probably find "useful data" indicating power state.

I will try, let me see.

About ZbName, yes I know, but now I am testing if I am able to do what you are propossing. LEt's go to find how to "capture" zbrecieved in berry.

[sfromis]

I'd also recommend options ZbNoprefix for simpler payloads, along with ZbNameKey to use the ZbName value as key in the payloads. Makes the format similar to Tasmota sensors.

[ortegafernando]

Hello, at this moment I have this code in berry (remember that I am testing, so I will change in future zbName).

I understand that with this code I could use pulsetime,... and other more complex functionalities as interlock, but I think that a boot up with the last saved state is impossible because the "code" is in te coordinator and the switches are in the zigbee board, isnt it?

Do you think that my code could be better (SURE !!! 😂), do I leave any other add_rule trigger missing?

tasmota.global.devices_present = 4
import string
tasmota.remove_rule('Power1#state')
tasmota.add_rule('Power1#state',
  def (value,trigger,data)
	tasmota.cmd(string.format('zbSend {"device":"0x6a96","endpoint": 1, "send":{"power":%s}}', value))
  end)
tasmota.remove_rule('Power2#state')
tasmota.add_rule('Power2#state',
  def (value,trigger,data)
	#print("POWER2#STATE value: ", value, " - trigger: ", trigger, " - data: ", data) 
	#print(string.format('zbSend {"device":"0x6a96","endpoint": 2, "send":{"power":%s}}', value))
	tasmota.cmd(string.format('zbSend {"device":"0x6a96","endpoint": 2, "send":{"power":%s}}', value))
  end)
tasmota.remove_rule('Power3#state')
tasmota.add_rule('Power3#state',
  def (value,trigger,data)
	tasmota.cmd(string.format('zbSend {"device":"0x6a96","endpoint": 3, "send":{"power":%s}}', value))
  end)
tasmota.remove_rule('Power4#state')
tasmota.add_rule('Power4#state',
  def (value,trigger,data)
	tasmota.cmd(string.format('zbSend {"device":"0x6a96","endpoint": 4, "send":{"power":%s}}', value))
  end)  
tasmota.remove_rule('zbreceived#0x6a96')  
tasmota.add_rule('zbreceived#0x6a96',
  def (value,trigger,data)
	#print("ZBRECIEVED: value: ", value, " - trigger: ", trigger, " - data: ", data) 
	if (value.contains("Endpoint") && string.count(value.tostring(),"Power")>0)
		if (value['Endpoint'] == 1)
			print("Power1:",value['Power'])
			tasmota.set_power(0, bool(value['Power']))
		end
		if (value['Endpoint'] == 2)
			print("Power2:",value['Power2'])
			tasmota.set_power(1, bool(value['Power2']))
		end
		if (value['Endpoint'] == 3)
			print("Power3:",value['Power3'])
			tasmota.set_power(2, bool(value['Power3']))
		end
		if (value['Endpoint'] == 4)
			print("Power4:",value['Power4'])
			tasmota.set_power(3, bool(value['Power4']))
		end		
	end
  end)

[sfromis]

If it works, it's ok 😄

Apart from the things I've already mentioned, that looks reasonable. You could simplify your ZbReceived handling for less repetitive code like this (not tested):

  var endpoint = value.find('Endpoint', 0)
  var channel = 'Power' + (endpoint == 1 ? "" : str(endpoint))
  var state = value.find(channel, -1)
  if state >= 0
    print(channel + ":", state)
    tasmota.set_power(endpoint - 1, bool(state))
  end

It would be possible to have same function for all 4 Powerx#state rules, picking the number out of the trigger parameter, but that makes it "less straightforward".

When it comes to last saved state.... If you config gpio relays instead of virtual ones, Tasmota could save "your" state of these across boots, and you could pick these up and set state. However, that would not be very "friendly" to endpoints haven gotten a different value without your coordinator code having seen the new value. The window for that may not be huge, but still worth remembering.

[ortegafernando]

Thanks a lot, i will try your code. Thanks.
About "last saved state", I think it is too complicated for me. I thought about it after reading about "persist" module
In irrigating system I think I will make a rule in case boot, all relays OFFs, but it is true that I have two devices: coordinator and the relay board itself. I need to do more test.

It would be possible to have same function for all 4 Powerx#state rules, picking the number out of the trigger parameter, but that makes it "less straightforward".

About this, is it this way: tasmota.add_rule('PowerX#state', with "X", or how could you "catch" all triggers in the same rule? Thanks

[sfromis]

By defining the function separately, instead of having an anonymous inline function.

def onePower(value,trigger,data)
  tasmota.cmd(string.format('zbSend {"device":"0x6a96","endpoint": 3, "send":{"power":%s}}', value))
end

That function is equivalent to (and can replace) the def ... end function definition. Of course, it the takes coding to derive the endpoint number, or you could pass it as an argument if you have each "rule" call that function with the relevant arguments.

When it comes to "last saved", my approach would (probably) be the other way around, having my code able to know what the state "should" be (based on the watering schedule), and push that out at boot time. Another strategy could be to issue a Zigbee command to query device status, to get your state updated. My point is that "last saved" is a "risky" strategy unless your code can manage the complete communication, which is "less feasible" if it has been offline, as the reason for that cannot really be known.

[ortegafernando]

Hi, I will want also to test/check the procedure of fake relays and rules. Do you now any disccusion or blog where I can start? I have tried to search information but I can't. Thanks (also because I have another zigbee gateway esp8266 based in other house)