Is there a fix for this Bug using Basic Rules machine.
More than Likely I'm using it wrong?
I tried turning on multiple Relays with Basic rules machine at the same time say 1PM
relay 1 and relay 2.
Relay 1 ON only for an instant the relay 2 Turns ON and stays ON.
Next test programed two separate ON times one minute apart.
Does the same thing: Relay 1 is on for one minute, when Relay 2 turns ON relay one turns OFF.
It sounds like this is in garage door mode.
These instructions don't make any sense to me, maybe someone else has changed modes?
- Default inching Function: Press the open relay by mobile phone, then cut off the pull-on immediately(default one second)
- Self-locking mode: trigger to Turn on/off connected devices
3.Interlock mode,wifi remote motor forward and reverse
1 Like
Thank you, doesn't to me either.
1 ) Didn't plan on having a mobile app?
2) What the heck is garage door mode hi hi
3) Need better instructions if possible.
It didn't come with instructions?
1 Like
Other than powering and pair none.
Found the mode switch on the board.
Seems to have three modes.
Just found one that lets me (with the buttons on the board) turn all the relays on, and they stay on, until I turn them off. So back to Rules machine to see what happens.
that may have fixed it, I will post here if it did.
@neonturbo is correct. This is an issue with the hardware configuration of the relay, and cannot be addressed in Hubitat.
These MHCOZY relays have two modes (maybe 3). Basically, they can work as:
- An inching relay, i.e you turn it on, and it turns off after a preset time determined by the hardware.
- A latched relay, i.e you turn it on, and it stays on until you turn it off.
These two modes are controlled by a button on the relay. Apparently you want it to be in latched mode.
Inching mode is most often used when someone needs a momentary switch, like if they are controlling a garage door opener.
5 Likes
Here is how I did it! Rules machine now works with the board.
By the way this article clears it up.
INCHING/SELF-LOCKING Switch – eWelink (coolkit.cc)
5 Likes
It would be interesting if input voltage has any impact (albeit unintended perhaps) to the radio signal robustness.
I've only powered these with 12VDC +/- 1V
Anyone used less than that and found the range not to their expectations?
Anyone else ever get this non-stop error off this device?
Mike I assume this line 76 in the driver? @mike.maxwell
dev:3152022-07-02 11:58:19.134 errorjava.lang.StringIndexOutOfBoundsException: String index out of range: -2 on line 76 (method parse)
dev:3152022-07-02 11:58:19.077 errorjava.lang.StringIndexOutOfBoundsException: String index out of range: -2 on line 76 (method parse)
dev:3152022-07-02 11:58:17.899 errorjava.lang.StringIndexOutOfBoundsException: String index out of range: -2 on line 76 (method parse)
dev:3152022-07-02 11:58:17.844 errorjava.lang.StringIndexOutOfBoundsException: String index out of range: -2 on line 76 (method parse)
What driver are you using for the parents and child devices?
Generic Zigbee Multi-Endpoint Switch on parent
and the children pick up Generic Component Switch by default
I will note that the switch is operable. Whether or not it is fully functional is another question, I'm not currently using all 4 channels.
1 Like
Obviously the driver doesnt work properly with that device.
Can post the fingerprint for this? As well as the link where you purchased it?
Source:
Working on fingerprint, waiting on power to come back to unit (on a remote solar setup). In the meantime, and I know this isn't everything, here's this:
- endpointId: 01
- application: 50
- softwareBuild:
- inClusters: 0003,0004,0005,0006,E000,E001,0000
- outClusters: 0019,000A
- model: TS0004
- isMultiEP: true
- manufacturer: _TZ3000_excgg5kb
While this is the same part that i currently have in production, the firmware is different, and its causing an error within our hubs parser routine, at this point i can only say its producing a malformed frame of somesort, since in the 5 years that method had been in use ive never seen this error.
Needless to say i wont be able to track this down efficiently without the part in hand.
OK - here's the fingerprint. I gotcha on the solution.
Just out of curiosity, could this error and its' frequency, compromise the mid-stream repeater by overwhelming it with traffic? I'm having a problem with that repeater.
One other thing to note, while I have the 2 channel version of this switch powering down every night and offering no errors, this 4 channel switch is on an underachieving solar configuration in need of a new battery and so the switch may be subject to a series of on/off cycles in the morning and/or evening solar transition times. It might be that this screws things up and causes an error?
fingerprint profileId:"0104", endpointId:"01", inClusters:"0003,0004,0005,0006,E000,E001,0000", outClusters:"0019,000A", model:"TS0004", manufacturer:"_TZ3000_excgg5kb"
ZCL version:03
Software Build Id:unknown
Model:TS0004
Manufacturer:_TZ3000_excgg5kb
Certainly that level of rubbish traffic isnt doing your mesh any favors.
Is there not a way to have these powered continuously? They shouldn't be powered down like that.
Well, the 2ch switch has been foolproof being on a circuit that is turned on in the AM and off in the PM, I worried about doing that for the reasons you infer...but it is on a circuit that is purposely shut down at night as a fail-safe approach, i.e. it becomes a "critical system" if it ever were to fail "on".
The 4ch switch I absolutely intend to be on 24/7 but the solar panel + battery + controller configuration I am experimenting with turns out to be not enough for the expanding application and charging requirements. So yes I will fix that power to this switch.
Thanks for confirming that this error does indeed create traffic on the mesh. I think I'll just disable the switch until I fix the power problem.
To be clear the error isn't creating traffic, the traffic already exists, the error is an artifact of the odd traffic, not the other way round...
2 Likes
Just a short question. I got the 1 channel relay, which I use as a door opener. The problem I have right now, is that it drops out of my mesh every two weeks. I have no idea why. Has anyone had the same experience? Right now, it is located about 1,5 meters (5 feet) away from my hub and I got several repeaters in my mesh (5 outlets and two Ikea repeaters). I'm using the multi Endpoint driver.
- endpointId: 01
- model: ZB-SW01
- application: 08
- isMultiEP: false
- manufacturer: eWeLink
Man if what I am having to go through this evening to get my LONG TIME STABLE Zigbee mesh repaired is indeed the result of that device.....WOW.
I still have a repeater I suspected before I discovered those device errors...at this point I won't know until tomorrow after things quiet down if unplugging that 4ch switch fixed things. But holy cow what a hassle basically getting multiple devices to talk again. No rejoins, but a few battery pulls.
