well that alone is telling, if taking that 4 channel off line caused other devices to need battery pulls, then it was being used as a router, which is the main reason these types of devices should always remain on line.
4 Likes
Quick question along these lines....
Can/Do repeaters repeat through repeaters or are they a single point link/hop back to the hub?
Don't think I've ever seen such through this table: IP/hub/zigbee/getChildAndRouteInfo
Yes
2 Likes
Check the stability of the power source. The sellers (and others) highlight the importance of that.
And....
I'm using the following driver for my SINGLE channel switch of this make.
Brand new 12 V AC power supply. That should do it. 
Ok, I'll give it a try. Thank you.
Anyone else having trouble renaming a child device on one of these?
Hi folks, looking for some assistance here.
I have this board running my pool pump and it's worked great for the month or so it's been in operation until I caught the pump on tonight when it should have been off. The pump should have shut off at 7:01pm. Checking the logs showed this;
dev:5772022-08-02 07:01:08.424 pm debugPool Pump Relays UNPROCESSED EP: null cluster: null attrId: null
dev:5772022-08-02 07:01:08.421 pm debugPool Pump Relays Parsed: [raw:catchall: 0000 8001 00 00 0040 00 23B5 00 00 0000 00 00 DD00726E8B949338C1A4B523, profileId:0000, clusterId:8001, clusterInt:32769, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:23B5, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[DD, 00, 72, 6E, 8B, 94, 93, 38, C1, A4, B5, 23]]
dev:5772022-08-02 07:01:08.401 pm debugPool Pump Relays UNPROCESSED EP: null cluster: null attrId: null
dev:5772022-08-02 07:01:08.399 pm debugPool Pump Relays Parsed: [raw:catchall: 0000 8001 00 00 0040 00 23B5 00 00 0000 00 00 DD00726E8B949338C1A4B523, profileId:0000, clusterId:8001, clusterInt:32769, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:23B5, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[DD, 00, 72, 6E, 8B, 94, 93, 38, C1, A4, B5, 23]]
dev:5772022-08-02 07:01:00.230 pm debugPool Pump Relays sending componentOff 577-03
Upon further investigation the "Type" was Zemismart zigbee wall switch multigang. Not sure why it had changed so I changed it back to the generic zigbee multi-end point switch I had set it up originally. I can communicate with the board fine and toggle the relays on/off but now the log is showing these errors:
dev:5772022-08-02 10:22:50.789 pm traceskipped descMap:[raw:23B50100001801002050E2FF2030E4FF2000, dni:23B5, endpoint:01, cluster:0000, size:18, attrId:0001, encoding:20, command:0A, value:50, clusterInt:0, attrInt:1, additionalAttrs:[[value:30, encoding:20, attrId:FFE2, consumedBytes:4, attrInt:65506], [value:00, encoding:20, attrId:FFE4, consumedBytes:4, attrInt:65508]]]
dev:5772022-08-02 10:22:50.786 pm debugdescMap:[raw:23B50100001801002050E2FF2030E4FF2000, dni:23B5, endpoint:01, cluster:0000, size:18, attrId:0001, encoding:20, command:0A, value:50, clusterInt:0, attrInt:1, additionalAttrs:[[value:30, encoding:20, attrId:FFE2, consumedBytes:4, attrInt:65506], [value:00, encoding:20, attrId:FFE4, consumedBytes:4, attrInt:65508]]]
dev:5772022-08-02 10:19:53.708 pm traceskipped descMap:[raw:23B50100001801002050E2FF2030E4FF2000, dni:23B5, endpoint:01, cluster:0000, size:18, attrId:0001, encoding:20, command:0A, value:50, clusterInt:0, attrInt:1, additionalAttrs:[[value:30, encoding:20, attrId:FFE2, consumedBytes:4, attrInt:65506], [value:00, encoding:20, attrId:FFE4, consumedBytes:4, attrInt:65508]]]
dev:5772022-08-02 10:19:53.706 pm debugdescMap:[raw:23B50100001801002050E2FF2030E4FF2000, dni:23B5, endpoint:01, cluster:0000, size:18, attrId:0001, encoding:20, command:0A, value:50, clusterInt:0, attrInt:1, additionalAttrs:[[value:30, encoding:20, attrId:FFE2, consumedBytes:4, attrInt:65506], [value:00, encoding:20, attrId:FFE4, consumedBytes:4, attrInt:65508]]]
dev:5772022-08-02 10:17:09.691 pm traceskipped descMap:[raw:23B50100001801002050E2FF2030E4FF2000, dni:23B5, endpoint:01, cluster:0000, size:18, attrId:0001, encoding:20, command:0A, value:50, clusterInt:0, attrInt:1, additionalAttrs:[[value:30, encoding:20, attrId:FFE2, consumedBytes:4, attrInt:65506], [value:00, encoding:20, attrId:FFE4, consumedBytes:4, attrInt:65508]]]
dev:5772022-08-02 10:17:09.688 pm debugdescMap:[raw:23B50100001801002050E2FF2030E4FF2000, dni:23B5, endpoint:01, cluster:0000, size:18, attrId:0001, encoding:20, command:0A, value:50, clusterInt:0, attrInt:1, additionalAttrs:[[value:30, encoding:20, attrId:FFE2, consumedBytes:4, attrInt:65506], [value:00, encoding:20, attrId:FFE4, consumedBytes:4, attrInt:65508]]]
dev:5772022-08-02 10:14:34.790 pm traceskipped descMap:[raw:23B50100001801002050E2FF2030E4FF2000, dni:23B5, endpoint:01, cluster:0000, size:18, attrId:0001, encoding:20, command:0A, value:50, clusterInt:0, attrInt:1, additionalAttrs:[[value:30, encoding:20, attrId:FFE2, consumedBytes:4, attrInt:65506], [value:00, encoding:20, attrId:FFE4, consumedBytes:4, attrInt:65508]]]
dev:5772022-08-02 10:14:34.788 pm debugdescMap:[raw:23B50100001801002050E2FF2030E4FF2000, dni:23B5, endpoint:01, cluster:0000, size:18, attrId:0001, encoding:20, command:0A, value:50, clusterInt:0, attrInt:1, additionalAttrs:[[value:30, encoding:20, attrId:FFE2, consumedBytes:4, attrInt:65506], [value:00, encoding:20, attrId:FFE4, consumedBytes:4, attrInt:65508]]]
dev:5772022-08-02 10:12:01.367 pm traceskipped descMap:[raw:23B50100001801002050E2FF2030E4FF2000, dni:23B5, endpoint:01, cluster:0000, size:18, attrId:0001, encoding:20, command:0A, value:50, clusterInt:0, attrInt:1, additionalAttrs:[[value:30, encoding:20, attrId:FFE2, consumedBytes:4, attrInt:65506], [value:00, encoding:20, attrId:FFE4, consumedBytes:4, attrInt:65508]]]
dev:5772022-08-02 10:12:01.364 pm debugdescMap:[raw:23B50100001801002050E2FF2030E4FF2000, dni:23B5, endpoint:01, cluster:0000, size:18, attrId:0001, encoding:20, command:0A, value:50, clusterInt:0, attrInt:1, additionalAttrs:[[value:30, encoding:20, attrId:FFE2, consumedBytes:4, attrInt:65506], [value:00, encoding:20, attrId:FFE4, consumedBytes:4, attrInt:65508]]]
Any suggestions/concerns? Thanks.
Which model are you using and which driver? I used to have problems with the single channel one, using the multi endpoint switch driver. It kept dropping out of my system every two weeks. Using the "Generic Zigbee Switch" driver, it is working stable now.
That's really weird.. Have you put your HE hub into Zigbee pairing mode for the need of adding another device around the same time? The driver, once assigned manually should not change even if there are other drivers containing fingerprints that may match the same device.
It seems like the device has reset itself for some reason (may be caused by a power supply spike due by the pump motor inductive load..). But the driver shouldn't change.
What you see in the logs after reverting back to the inbuilt generic zigbee multi-end point switch driver are not errors, but some device-specific reports that can't be handled by a generic driver. This is not something to worry about, just switch the Debug logging off.
1 Like
I'm currently using the multi endpoint driver on a 4 relay MHCOZY board. I have added several devices since and don't recall making any changes to the relay board in the Device Information settings. I have now turned off Debug logging.
I actually mocked up the board on my desk, wrote the rule and let it run for a week before actually wiring it to the pump. No issues.
Thinking about this further... with the updates that have been released in the last two months, after each update my Sengled bulbs(4) around the house have stopped working. Meaning, they no longer respond to commands and are stuck in the state previous to the update. In the end the fix is simple, just power cycle them which fortunately is easy to do. No clue if this has anything to do with the relay board though.
As far as the inductive load goes, this board is controlling the digital inputs(5v) to control the pump and not the actual pump motor(It's 220v). It's a Pentair variable speed pump(300 - 3450rpm).
Let me take a moment to explain why I'm using this board with a brief rant. Whoever assembled this pump at the factory did a sloppy job and squished a gasket out of place during assembly. This caused water to leak in and eventually damage the controller interface board to the motor. The end result was my pump would turn on at random times in the middle of the night and the user buttons wouldn't respond to input. I was able to clean off the water damage and get it working but the issues returned months later. They don't sell a replacement board individually so you have to buy the whole upper assembly to the tune of $550+.
It turns out Pentair uses a 9 pin port on the side for external control. At first it thought it probably used some proprietary communication protocol but it turns out it's just 5v. When a certain pin sees the 5v, it executes it preprogrammed speed that I previously programmed in. It even sends out it's own 5v. So it turns out all I needed to (re)automate the pump were 4 relays(1 for each speed) with dry contacts. Now Pentair tries to prevent you from doing your own wiring by using a proprietary 9 pin connector, changing the color coding on each side of the connector and only using a few of the 9 pins.
So long story short... I was able to fix my pump for less than $30. Hats off to whomever decided to add this board to the Hubitat environment. Thanks folks.
2 Likes
Hats off to you figuring this out w/o burning anything up (my fear whenever I start look at something like that). I have a slick chicken coop door controller with some terminal points on the internal board for which the vendor claims no information for how they can be used.
There is some labeling that peaked my interest in giving HE control above and beyond what the door controller offers. BUT... it ain't cheap....and it's not broken like your pump controller was.
Interesting ... I had 9 Sengled bulbs stop working over the past month. Not saying that there is a connection, but not saying that there isn't.
I did something similar with the Pentair SuperFlo VS pump at our old house. That uses a special 6-pin cable, but the same basic idea (5V, Ground, Speeds 1-4). I happened to use a Zen16 and only accessed 3 speeds, but still very much worth it. Glad this worked out for you!
Once I realized out how it works I figured what's the worst that can happen... I damage an already damaged board? So be it as there's a lot less at stake. I'm already looking at over $500 so lets go for the cheaper option first and see if it works. Otherwise I probably wouldn't have been as daring.
Which brings up another point. This will be the 2nd time a Hubitat solution has saved me some serious coin. The 1st was when the ice maker line on my fridge started leaking and if not caught would have flooded thru the wall to my hardwood flooring in the living room. My Linkind water sensor alerted me and saved the day. So my setup has already paid for itself by preventing some costly repairs and it only makes sense to build it out further. At least that's what I'm telling the wife and Amazon currently has Sonoff Zigbee S31 outlets at 33% off.
2 Likes
Hi Everyone,
I have an interesting issue to report - I have recently purchased another MHCOZY 4 Channel Zigbee Relay unit (this is now my 3rd unit) the other two were purchased a while ago and are working very well.
Background -
When l pair this latest unit, Hubitat is wrongly recognising this device as a 'Tuya Metering Zigbee Plug' per the screenshot below. I then manually change this to 'Generic Zigbee Multi-Endpoint Switch' and the device itself functions correctly,
Issue: Within the logs, l am receiving every minute an error message, which l suspect is due left over parameters from the above 'Tuya Metering Zigbee Plug'. (wrong driver)
Below is the fingerprint data
Request - Could someone please update the driver to include this manufacture so it will then be recognised as the correct device.
Thank you
In the mean time, you can temporarily use the device driver called Device and delete settings left over from a previously wrong driver. Just select all of the Delete All options, then change back to the correct driver.
3 Likes
Excellent! That did the trick - thank you
I wasn't aware of the 'Device' and being able to delete the other options etc.
Great tip!!
1 Like
_TZ3000_u3oupgdy
@carnsew this device fingerprint looks strange (inCluster 2101 ), seems like it was not paired successfully to HE.
If it works OK, you can leave it as it is. But if you encounter any problems, the best approach would be to delete the device from its web page (REMOVE DEVICE) and pair it again to HE as a new device, in a close distance to HE hub. Once it works with the right driver (the inbuilt the generic zigbee multi-end point switch), you can move it to its final destination, the device will choose a Zigbee repeater if needed.
Hi kkossev,
I have done this 4x times and each time it comes up with same recognized device 'Tuya Metering Zigbee Plug'. I suspect the driver needs to be updated to include this (new) manufacturer as 'others' will run into the same issue over time.
Can you switch temporarily to the ‘device’ driver, click on ‘Get Info’ button and then copy and paste here the device fingerprint that should appear in the logs?
For comparison, this is the clusters list for the same device when paired to SmartThings :
Hi Kkossev,
Does this help (see below)
| Manufacturer: | _TZ3000_u3oupgdy |
|---|---|
| Endpoint 01 application: | 50 |
| Endpoint 01 endpointId: | 01 |
| Endpoint 01 idAsInt: | 1 |
| Endpoint 01 inClusters: | 0003,0004,0005,0006,E000,E001,0000 |
| Endpoint 01 initialized: | true |
| Endpoint 01 manufacturer: | _TZ3000_u3oupgdy |
| Endpoint 01 model: | TS0004 |
| Endpoint 01 outClusters: | 0019,000A |
| Endpoint 01 profileId: | 0104 |
| Endpoint 01 stage: | 4 |
| Endpoint 02 application: | unknown |
| Endpoint 02 endpointId: | 02 |
| Endpoint 02 idAsInt: | 2 |
| Endpoint 02 inClusters: | 0004,0005,0006,E001 |
| Endpoint 02 initialized: | true |
| Endpoint 02 manufacturer: | unknown |
| Endpoint 02 model: | unknown |
| Endpoint 02 profileId: | 0104 |
| Endpoint 02 stage: | 4 |
| Endpoint 03 application: | unknown |
| Endpoint 03 endpointId: | 03 |
| Endpoint 03 idAsInt: | 3 |
| Endpoint 03 inClusters: | 0004,0005,0006,E001 |
| Endpoint 03 initialized: | true |
| Endpoint 03 manufacturer: | unknown |
| Endpoint 03 model: | unknown |
| Endpoint 03 profileId: | 0104 |
| Endpoint 03 stage: | 4 |
| Endpoint 04 application: | unknown |
| Endpoint 04 endpointId: | 04 |
| Endpoint 04 idAsInt: | 4 |
| Endpoint 04 inClusters: | 0004,0005,0006,E001 |
| Endpoint 04 initialized: | true |
| Endpoint 04 manufacturer: | unknown |
| Endpoint 04 model: | unknown |
| Endpoint 04 profileId: | 0104 |
| Endpoint 04 stage: | 4 |
| Endpoint F2 application: | unknown |
| Endpoint F2 endpointId: | F2 |
| Endpoint F2 idAsInt: | 242 |
| Endpoint F2 initialized: | true |
| Endpoint F2 manufacturer: | unknown |
| Endpoint F2 model: | unknown |
| Endpoint F2 outClusters: | 0021 |
| Endpoint F2 profileId: | A1E0 |
| Endpoint F2 stage: | 4 |
