[External Converter]: Tuya TS0601 _TZE200_rgeapp2c 2 switches + 2 covers Semicom touch panel. External converter problem

[Simchon]

Link

https://www.semicom.co.il/sz-4gev2t2n-w

Database entry

{"id":3,"type":"Router","ieeeAddr":"0xa4c138cfb65f95d9","nwkAddr":57685,"manufId":4417,"manufName":"_TZE200_rgeapp2c","powerSource":"Mains (single phase)","modelId":"TS0601","epList":[1,242],"endpoints":{"1":{"profId":260,"epId":1,"devId":81,"inClusterList":[4,5,61184,0],"outClusterList":[25,10],"clusters":{"genBasic":{"attributes":{"65503":"-��1i.��1i.��1i","65506":53,"65508":0,"65534":0,"stackVersion":0,"dateCode":"","manufacturerName":"_TZE200_rgeapp2c","zclVersion":3,"appVersion":65,"modelId":"TS0601","powerSource":1,"hwVersion":1}}},"binds":[],"configuredReportings":[],"meta":{}},"242":{"profId":41440,"epId":242,"devId":97,"inClusterList":[],"outClusterList":[33],"clusters":{},"binds":[],"configuredReportings":[],"meta":{}}},"appVersion":65,"stackVersion":0,"hwVersion":1,"dateCode":"","zclVersion":3,"interviewCompleted":true,"interviewState":"SUCCESSFUL","meta":{"configured":"0.0.0"},"lastSeen":1782834139568}

Zigbee2MQTT version

2.12.0-1

External converter

const tuya = require('zigbee-herdsman-converters/lib/tuya');
const exposes = require('zigbee-herdsman-converters/lib/exposes');

const e = exposes.presets;
const ea = exposes.access;

const definition = {
    fingerprint: [
        {
            modelID: 'TS0601',
            manufacturerName: '_TZE200_rgeapp2c',
        },
    ],
    model: 'TS0601_TZE200_rgeapp2c',
    vendor: 'Tuya',
    description: 'Semicom touch panel: 2 lights + 2 shutters)',
    fromZigbee: [tuya.fz.datapoints],
    toZigbee: [tuya.tz.datapoints],
    onEvent: tuya.onEventSetTime,
    configure: tuya.configureMagicPacket,
    //options: [exposes.options.invert_cover()],
    exposes: [
        // Expose Switches to Home Assistant
        e.switch().withEndpoint('s1'),
        e.switch().withEndpoint('s2'),
        // Expose Shutters/Covers to Home Assistant
        e.cover_position().withEndpoint('c1').setAccess('position', ea.STATE_SET),
        e.cover_position().withEndpoint('c2').setAccess('position', ea.STATE_SET),
    ],
    endpoint: (device) => {
        return {'s1': 1, 's2': 1, 'c1': 1, 'c2': 1};
    },
    meta: {
        multiEndpoint: true,
        tuyaDatapoints: [
            // --- LIGHTS / SWITCHES ---
            [101, 'state_s1', tuya.valueConverter.onOff],
            [102, 'state_s2', tuya.valueConverter.onOff],
            
            // --- SHUTTERS / COVERS ---
            // Cover 1 (DP 1 for state/control, DP 2 for position)
            [1, 'state_c1', tuya.valueConverterBasic.lookup({'OPEN': tuya.enum(0), 'STOP': tuya.enum(1), 'CLOSE': tuya.enum(2)})],
            //[1, 'state_c1', tuya.valueConverter.coverState],
            [2, 'position_c1', tuya.valueConverter.coverPosition],
            
            // Cover 2 (DP 4 for state/control, DP 5 for position)
            [4, 'state_c2', tuya.valueConverterBasic.lookup({'OPEN': tuya.enum(0), 'STOP': tuya.enum(1), 'CLOSE': tuya.enum(2)})],
            //[4, 'state_c2', tuya.valueConverter.coverState],
            [5, 'position_c2', tuya.valueConverter.coverPosition],
            
        ],
    },
};

module.exports = definition;

What does/doesn't work with the external definition?

Since this device came up as unsupported, I wrote an external converter for it.
This converter works very well at the Z2M device level (both controlling and getting the correct status from the panel).
But at the HASS level, status from the covers is wrong:
button pressed => reported activity (comment):
Down (close) => was closed (correct)
Down again (stop) => was opened (should be "was stopped")
Up (open) => No activity (should be "was opened").

I also tried a simple one-cover converter to try to isolate the problem, and it behaves the same: perfect at the Z2M level, but bad state at the HASS/MQTT device. The one-cover converter I used:

const tuya = require('zigbee-herdsman-converters/lib/tuya');
const exposes = require('zigbee-herdsman-converters/lib/exposes');

const e = exposes.presets;
const ea = exposes.access;

const definition = {
fingerprint: [
{
modelID: 'TS0601',
manufacturerName: '_TZE200_rgeapp2c',
},
],
model: 'TS0601_TZE200_rgeapp2c',
vendor: 'Tuya',
description: 'Semicom 1 cover test for 2 lights + 2 covers panel',
fromZigbee: [tuya.fz.datapoints],
toZigbee: [tuya.tz.datapoints],
onEvent: tuya.onEventSetTime,
configure: tuya.configureMagicPacket,
//options: [exposes.options.invert_cover()],
exposes: [
e.cover_position().setAccess('position', ea.STATE_SET),
],
meta: {
tuyaDatapoints: [
[1, 'state', tuya.valueConverterBasic.lookup({
OPEN: tuya.enum(0),
STOP: tuya.enum(1),
CLOSE: tuya.enum(2),
})],
[2, 'position', tuya.valueConverter.coverPosition],
],
},
};

module.exports = definition;

Notes

I would greatly appreciate your help with this.
Thank you

[github-actions]

🙏 Thank you for creating this issue and sharing your external converter!

In case all features work, please submit a pull request on this repository so the device can be supported out-of-the-box with the next release.
For instructions on how to create a pull request see the docs.

If NOT all features work, please follow the How To Support new devices.
Since this is a Tuya also consider How To Support new Tuya devices.

If you need help with the process, feel free to ask here and we'll be happy to assist.

[Simchon]

I already identified the device data points and wrote an external converter for the device.
Everything works well at the Z2M level, but the two covers report wrong activity states at the HASS/MQTT device level (see details above).
I would really appreciate your help with this issue - Thank you

[SamHartleyFixes]

Took a proper look at this one. Your converter is basically right - the structure matches the repo's own two-rail cover def (TS0301_dual_rail) almost line for line, which is why control and the raw Z2M state both look fine. The wrong state in HA comes down to a single detail.

tuya.valueConverter.coverPosition derives open/closed from the reported position and pushes it out as publish({state: ...}) - a bare state key with no endpoint suffix. On your multi-endpoint device the cover entities are bound to state_c1 and state_c2, so that position-derived state lands on plain state, which nothing reads. Your DP1/DP4 OPEN/STOP/CLOSE lookup only writes state_c1/state_c2 on an actual button press, so once a position report comes in, the per-cover state is left stale. That's what you're seeing.

Fix is to swap coverPosition for a tiny per-cover converter that publishes the endpoint-suffixed state. Keep your DP1/DP4 control lookup exactly as is:

const coverPositionFor = (ep) => ({
to: (v, meta) => (meta.options.invert_cover ? 100 - v : v),
from: (v, meta, options, publish) => {
const position = options.invert_cover ? 100 - v : v;
publish({[state_${ep}]: position === 0 ? 'CLOSE' : 'OPEN'});
return position;
},
});

// then in meta.tuyaDatapoints:
[2, 'position_c1', coverPositionFor('c1')],
[5, 'position_c2', coverPositionFor('c2')],

One honest caveat so you don't chase a ghost: "Stop should report stopped" isn't reachable here. Because the cover is exposed with position, HA derives the entity state from position and only ever shows open/closed (plus opening/closing while it travels) - STOP is a command, not a state it can hold. With the change above that resolution will at least be correct per cover, and the Stop button keeps working.

Two things I can't check without your panel: whether DP2/DP5 report position as 0=closed/100=open or inverted - if open and closed come out backwards, either turn on the invert_cover option or swap coverPosition for coverPositionInverted inside the helper. And whether the panel reports live position during travel or only on settle - if only on settle, the state will still be right, just updated when the blind stops rather than continuously.

Hope that sorts it - let me know how it goes.

[Simchon]

Thank you so much for your help.
In fact, I am almost not interested in Position. State is much more important for me (I am fine, I think, with getting/controlling only the cover State) .
At the Z2M level the device screen buttons and the state include Open/Close/Stop, based only on buttons pressed and relay state (regardless of Position):

1. Down button pressed (down led on) => state: Close
2. Down button pressed (down led off) => state: Stop
3. Up button pressed (up led on) => state: Open
4. Up button pressed (up led off) => state: Stop

Is it possible to reproduce this state reporting behavior, based on buttons pressed, at the HA level? Maybe the converter should include only cover_state?

Thank you again for your help.

Here is a screenshot of the Z2M device at a Stop state:

[SamHartleyFixes]

Glad the position side made sense - and this is actually the easier path, because you already have the exact datapoint you need.

Your DP1 and DP4 are the work-state points: your own converter maps them 0=OPEN, 1=STOP, 2=CLOSE. That's the button/relay state the panel screen shows, not a position-derived one. So the way to get the Open/Close/Stop reporting you want is to drop position entirely and expose a plain state-only cover, keeping your existing lookup on DP1/DP4.

e.cover() (as opposed to e.cover_position()) gives you exactly that - in the repo it's a single state enum with OPEN/CLOSE/STOP and no position feature at all. Put .withEndpoint('c1') on it and its property becomes state_c1, which is where your lookup already writes. So:

exposes: [
    e.switch().withEndpoint('s1'),
    e.switch().withEndpoint('s2'),
    e.cover().withEndpoint('c1'),
    e.cover().withEndpoint('c2'),
],
...
meta: {
    multiEndpoint: true,
    tuyaDatapoints: [
        [101, 'state_s1', tuya.valueConverter.onOff],
        [102, 'state_s2', tuya.valueConverter.onOff],
        [1, 'state_c1', tuya.valueConverterBasic.lookup({OPEN: tuya.enum(0), STOP: tuya.enum(1), CLOSE: tuya.enum(2)})],
        [4, 'state_c2', tuya.valueConverterBasic.lookup({OPEN: tuya.enum(0), STOP: tuya.enum(1), CLOSE: tuya.enum(2)})],
    ],
},

Just drop the DP2/DP5 position rows and the coverPosition converter with them. The reason that matters: coverPosition derives open/closed from position and publishes it as a bare state key with no endpoint suffix, so on a multi-endpoint device it lands on plain state (which nothing reads) and leaves your real per-cover state stale. Removing it clears that up. (Side note: tuya.valueConverter.coverState - the line you had commented out - doesn't exist in the current converters, so leaving it commented was correct. The lookup you wrote is the right mechanism.)

Now the honest caveat, because I don't want you chasing something HA won't give you. A cover entity in HA only ever rests at open or closed (with opening/closing shown while it travels). The MQTT cover does accept a stopped payload, but when a stop arrives without a position topic - which is exactly your case now - HA resolves it back to open or closed based on the last direction rather than holding "Stopped." So on the cover card, Stop will still work as a button, but it won't sit there reading "Stopped."

If seeing the literal Open / Stop / Close text as a resting value matters more than having a cover card, then instead of the cover, expose that datapoint as an enum. The one thing to watch is that the exposed property has to match the datapoint key exactly, and .withEndpoint adds the _c1 suffix for you - so name the enum cover_state, not the already-suffixed name:

e.enum('cover_state', ea.STATE, ['OPEN', 'STOP', 'CLOSE']).withEndpoint('c1'),

and bind DP1 to the resulting property:

[1, 'cover_state_c1', tuya.valueConverterBasic.lookup({OPEN: tuya.enum(0), STOP: tuya.enum(1), CLOSE: tuya.enum(2)})],

That gives you a sensor in HA that literally shows OPEN, STOP or CLOSE as reported by the buttons - the closest thing to the Z2M screen behaviour you screenshotted. Note it's one or the other per datapoint, not both: a given DP only maps to a single property, so you'd swap the cover row for the enum row rather than adding a second row for DP1.

One thing to test on your actual panel: confirm DP1/DP4 really do emit an unsolicited report on each button press (not only when you command via MQTT). Your description says the Z2M state already tracks the buttons, so it should - but watch the Z2M state for a manual up/down/stop and make sure state_c1 (or cover_state_c1) updates each time. If a press only shows in the log and not on the entity, tell me what the DP frame looks like and we'll sort the mapping.

[Simchon]

Thank you so much.
I tried the enum trick, but it is a sensor that cannot control the cover. Is there a way for HA to both control and get the cover OPEN/CLOSE/STOP state?
To your question:
At the Z2M level, with e.cover() in the converter, I do see both physical and screen button presses translate to OPEN/CLOSE/STOP states at the device view. But with e.cover(), as you so well described, at the HA level I see only closed/opened state with STOP ignored.

So, if I understand correctly, I have 3 options:

1. Use e.cover(), in which case I can control OPEN/CLOSE/STOP, but read only opened/closed
2. Use e.cover_position(), in which case I can control OPEN/CLOSE/STOP or Position, but read only opened/closed/opening/closing/Position
3. Use e.enum(), which is a sensor only, that reads OPEN/CLOSE/STOP state
   Is this correct? No option to both control and read OPEN/CLOSE/STOP at the HA level?

Thanks again for your help.

[SamHartleyFixes]

Yeah, your three-option summary is basically right, and I want to be straight with you about why none of them does what you want on its own — it's not a config knob you're missing, it's a real limitation in how the pieces fit together.

On your summary

1. cover → you control open/close/stop, HA reads open/closed only. Correct.
2. cover_position → control + position, and HA derives opening/closing/open/closed from the position DP. Correct — but note those "opening/closing/stopped" states are derived by HA from position movement, not a stored readable value, and it needs a real 0–100% position DP to work. If your panel only reports the 0/1/2 work-state and no position, option 2 doesn't really apply to you.
3. enum → read-only OPEN/STOP/CLOSE sensor, can't control. Correct.

And your core question — is there one option that does both control and holds the literal OPEN/STOP/CLOSE reading — the honest answer is no, not from a single HA entity. Two reasons, both real:

• A HA cover entity only has open/closed/opening/closing. "Stopped" isn't a state it will hold and show you. So a cover can do stop, but it can't display stop. That's HA's cover model, not the converter.
• On the converter side, the standard Tuya handler (fz.datapoints) walks the datapoints and does datapoints.find(d => d[0] === dpId) — first match wins, one row per DP. So you can't add two tuyaDatapoints rows for the same DP (one → cover, one → enum); the second is never reached.

The real fix: two exposes, both fed from one DP

You expose two things — a cover (control + open/closed) and a separate read-only enum (the literal OPEN/STOP/CLOSE) — and you publish both from the same DP.

The mechanism that makes this work: a tuyaDatapoints row whose from converter returns an object with multiple keys gets merged into state (z2m does Object.assign(result, converter.from(...)) when the row's property name is left null). This is a well-worn in-tree pattern — it's exactly how Tuya's power converters emit {voltage, current, power} from a single DP (phaseVariant). So one DP frame can publish both the cover state and the enum state at once. You don't need a full custom fromZigbee for this — a single multi-key value-converter row does it, and it survives upgrades better.

Rough shape (external converter — adjust DP numbers/endpoints to your panel; you said DP1/DP4 are the two channels). A tiny converter factory, one per channel, mirroring how phaseVariant2WithPhase("a") works:

// enum int -> {enum sensor key, cover state key}; STOP intentionally leaves the cover alone
const workstate = (ep) => ({
    from: (v) => {                    // v is the DECODED enum int (0/1/2), not a raw buffer
        const enumLookup  = {0: 'OPEN', 1: 'STOP', 2: 'CLOSE'};
        const coverLookup = {0: 'OPEN', 2: 'CLOSE'};   // STOP is not a cover state
        const out = {[`cover_state_${ep}`]: enumLookup[v]};
        if (coverLookup[v] !== undefined) out[`state_${ep}`] = coverLookup[v];
        return out;
    },
});

Then in the definition:

• in meta.tuyaDatapoints, give each channel DP a null property name so the multi-key object gets merged, e.g.
  [1, null, workstate('c1')], [4, null, workstate('c2')]
  (do NOT also list those DPs with a plain state_cX row — the find() above means only the first row for that DP ever runs),
• keep your existing e.cover().withEndpoint('c1'/'c2') for control + open/closed,
• add e.enum('cover_state_c1', ea.STATE, ['OPEN','STOP','CLOSE']) and the c2 one as read-only sensors,
• keep your existing toZigbee/control rows for the cover — the cover still needs to send open/close/stop; this only changes the read path.

If you'd rather do the whole read side by hand, a full custom fromZigbee (looping msg.data.dpValues and returning the same keys) works identically — just heavier to maintain. Either way the trick is the same: one DP in, two keys out.

Being honest about what needs testing on your hardware — I'm reasoning from the converter framework, not from your panel, so a couple of things genuinely need a quick check:

• The raw enum values. I assumed 0=OPEN, 1=STOP, 2=CLOSE. Turn on debug logging, press a physical button, and confirm the DP number and the raw byte you actually get. If the ordering differs, fix the two lookups.
• The command type. fz.datapoints already listens on commandDataResponse, commandDataReport, commandActiveStatusReport and its alt — so as long as you go through tuyaDatapoints (the null-property row above), you don't have to hardcode a type. If you go full custom-fz instead, watch which command your panel reports work-state on, because some report on commandActiveStatusReport rather than the data-report types.
• STOP handling on the cover. I deliberately don't touch state_cX on STOP, so a mid-travel stop doesn't yank the cover to a wrong open/closed — the enum carries the literal truth, the cover carries the actionable state. Watch that the cover doesn't sit on a stale value in a way that bugs you; if it does, that's a preference call, not a bug.

If maintaining an external converter across z2m upgrades is more than you want, the low-effort fallback is: run the plain cover for control + open/closed and get the OPEN/STOP/CLOSE reading as a companion HA template sensor off the DP. No custom JS, still both readings — just not from one tidy device definition.

So: your instinct was right that no single option does both. But you can have both side by side — one DP publishing two keys, cover + enum. If you paste a debug log of a physical button press (DP number, command type, raw bytes), I'll tighten the lookups to your exact panel.

— Sam

[Simchon]

Thanks a lot, Sam, for your detailed answer.
To your question:
The correct mapping is indeed 0=OPEN, 1=STOP, 2=CLOSE. It works well for Z2M & HA control and for Z2M device state reading.

I'm intrigued by your suggestion:
"If maintaining an external converter across z2m upgrades is more than you want, the low-effort fallback is: run the plain cover for control + open/closed and get the OPEN/STOP/CLOSE reading as a companion HA template sensor off the DP. No custom JS, still both readings — just not from one tidy device definition."
How can this be done? (I am new to HA & Z2M). Can you please walk me through the process or send a config file?

Thank you so much again for your help & prompt replies
Simchon

[SamHartleyFixes]

Hi Simchon — thanks for posting the full converter, that makes this much easier to answer precisely, because I can see exactly what you're already publishing.

First, a correction to something I said earlier. I'd suggested a "plain cover plus a template sensor, no converter change" fallback, and implied Home Assistant might have nothing to read. Looking at your actual converter, that was me being sloppy — your state value IS already being published. Let me walk through what's really going on, because it changes the advice.

What's actually in your MQTT payload right now

Home Assistant can only read fields that Z2M has already published to MQTT. Whenever your device state changes, Z2M publishes a JSON message to a topic named after the device, e.g.:

topic:   zigbee2mqtt/<your device name>
payload: {"state_c1": "OPEN", "position_c1": 40, "state_c2": "CLOSE", ...}

Here's the key detail for your converter: this line in your meta.tuyaDatapoints

[1, 'state_c1', tuya.valueConverterBasic.lookup({'OPEN': tuya.enum(0), 'STOP': tuya.enum(1), 'CLOSE': tuya.enum(2)})],

is what puts state_c1 (as the string "OPEN"/"STOP"/"CLOSE") into that JSON payload. Same for state_c2 on DP4. Publishing to the payload is driven by your tuyaDatapoints mapping — not by the exposes array. Your exposes array only controls what Home Assistant auto-creates as entities.

So state_c1 and state_c2 are already sitting in your device's JSON right now. That's good news: it means the readable value already exists, and you have two clean ways to surface it in HA.

Why the HA cover shows wrong states (the thing you actually asked about)

Your report — press close → "was closed" (right), press stop → "was opened" (wrong), press open → nothing — is a known rough edge with Tuya covers in Home Assistant. Your e.cover_position() becomes an HA cover entity, and HA's cover integration tries to derive open/closed/opening/closing from the OPEN/CLOSE/STOP state plus position, and it doesn't line up cleanly for these panels (STOP in particular confuses it). That's a limitation of how the cover entity interprets the state, not something wrong with your DP mapping — your Z2M-level state is correct, which is exactly what you're seeing.

I want to be honest up front: the step below does not magically fix the cover entity's display. What it does is give you a separate, dead-reliable read-only sensor showing the true OPEN/STOP/CLOSE the panel reported, which is usually what people actually want to see and automate on. If your goal is specifically to make the cover tile animate correctly, that's a deeper HA cover-mapping issue and worth its own thread — say the word and we can dig in.

Recommended: expose state as a readable enum (small addition to your converter)

Right now state_c1/state_c2 are published but not declared in exposes, so HA discovery doesn't create an entity for them. Declaring them as read-only enums is a one-time addition and then HA makes the sensors for you automatically — no HA YAML at all.

In your exposes array, add two lines (keep everything you already have):

exposes: [
    e.switch().withEndpoint('s1'),
    e.switch().withEndpoint('s2'),
    e.cover_position().withEndpoint('c1').setAccess('position', ea.STATE_SET),
    e.cover_position().withEndpoint('c2').setAccess('position', ea.STATE_SET),

    // NEW: declare the state you're already publishing, so HA creates a sensor for it
    e.enum('state', ea.STATE, ['OPEN', 'STOP', 'CLOSE']).withEndpoint('c1'),
    e.enum('state', ea.STATE, ['OPEN', 'STOP', 'CLOSE']).withEndpoint('c2'),
],

A few notes so this is clear and not cargo-culted:

• The property name is state and .withEndpoint('c1') is what makes it publish/expose as state_c1 — matching the 'state_c1' key already in your tuyaDatapoints. Don't rename it to anything else, or the expose and the payload won't line up.
• ea.STATE means "read-only, published in the state JSON." That's the bit that both keeps the value in the payload and tells HA discovery to make it a sensor.
• You do not need to touch fromZigbee. You're using tuya.fz.datapoints, which already sets state_c1/state_c2 from your datapoint mapping. Adding the expose is the whole change.
• One reason this is the right path on your version (2.12): since Z2M 2.0, external converters can no longer push HA entities through the old homeassistant property — HA entities are driven entirely by exposes. So declaring the enum in exposes is the way to get a discovered entity.

Then restart Z2M, press a button on the panel, and you should see new entities appear on the device in HA, named roughly sensor.<device>_state_c1 and ..._state_c2. Drop them on a dashboard:

type: entities
entities:
  - entity: sensor.<device>_state_c1
  - entity: sensor.<device>_state_c2

(Replace <device> with your device's actual name. If you're not sure of the exact entity id, open the device page in HA — Settings → Devices & Services → your Zigbee2MQTT device — and the new sensors will be listed there.)

You'll also want the MQTT integration added in HA (Settings → Devices & Services → Add Integration → MQTT) and Z2M's HA integration on. If you're on the official Zigbee2MQTT add-on it's on by default; if you installed Z2M another way, confirm your Z2M configuration.yaml has:

homeassistant:
  enabled: true

Alternative: no converter change at all (a manual HA sensor)

Because state_c1/state_c2 are already in your payload, you can also just build the HA sensor by hand and skip touching the converter entirely. Add this to your HA configuration.yaml:

mqtt:
  sensor:
    - name: "Cover State C1"
      state_topic: "zigbee2mqtt/<your device name>"
      value_template: "{{ value_json.state_c1 }}"
    - name: "Cover State C2"
      state_topic: "zigbee2mqtt/<your device name>"
      value_template: "{{ value_json.state_c2 }}"

value_json is that whole JSON payload from the device topic, and .state_c1 pulls out the one field. Replace <your device name> with your device's friendly name and restart HA.

Both routes read the same underlying value. The enum-in-exposes route is tidier (HA makes and names the sensors for you, and they follow the device), so I'd lean that way — but if you'd rather not reopen the converter, the manual sensor genuinely works today, since the field is already published.

Short version

• Your state_c1/state_c2 are already in the MQTT JSON — your tuyaDatapoints lookup publishes them. So a readable value already exists.
• They're just not declared in exposes, so HA doesn't auto-create a sensor. Add e.enum('state', ea.STATE, ['OPEN','STOP','CLOSE']).withEndpoint('c1'/'c2') and restart Z2M — no fromZigbee change, no HA YAML.
• Or, since the field is already published, build a manual mqtt: sensor: with value_json.state_c1 — no converter change needed.
• Heads up: this gives you a reliable readable state sensor, but it does not by itself fix the cover entity's open/stop/close display — that's a separate, known Tuya cover-mapping quirk in HA. Happy to dig into that one next if that's the part you care about.

— Sam

[Simchon]

Thank you so much Sam.
I inserted the two e.enum() lines into the converter and magically two sensors, state_c1 and state_c2, appeared in the device. This is exactly what I was looking for.
I tested everything a bit and so far everything looks very good.
I'll continue testing tomorrow and update.

Here is how it looks on my screen - beautiful:

[SamHartleyFixes]

Ah, that's brilliant — two sensors showing OPEN/STOP/CLOSE is exactly the result we were after. 👍 Nice work getting the converter edits in yourself.

No charge for any of this — I enjoy these puzzles. If it saved you the headache and you feel like it, there's a tip jar here: https://buy.stripe.com/fZu00ifCFeaobw84c4b7y0b — genuinely no pressure though. Enjoy the panel, and give me a shout if the cover-tile display ever starts bugging you (that's the separate quirk we flagged). Cheers.

[Simchon]

I now have two optional converters that work well. One exposes a "cover_position" and the other "cover", while both use the enum trick to expose a sensor with return states OPEN/CLOSE/STOP.
Both converters work well in my pyscript automations, but while pressing the buttons, the "cover_position" converter results in multiple HA log warnings of the form :
2026-07-05 16:51:00.829 WARNING (MainThread) [homeassistant.helpers.template] Template variable warning: 'dict object' has no attribute 'position' when rendering '{{ value_json["position"] }}'

Since both converters show very similar functionality, I tend to favor the "cover", as it is warning-free.
Sam, I'd love to hear your opinion on this matter.

[SamHartleyFixes]

Glad you got two working paths -- and I'd back your instinct: go with cover.

The warning is the tell. 'dict object' has no attribute 'position' means the position template {{ value_json["position"] }} runs against every message the device sends, and the ones that don't carry a position (the button-press / state updates) have no position key, so the lookup errors and logs. It's harmless noise, but it's also telling you something real: this panel reports discrete OPEN/CLOSE/STOP, not a true 0-100% position. So a cover_position entity puts a slider in front of you that can't actually reflect where the blind physically is -- it looks richer but it's a little fictional.

cover matches what the hardware actually knows, which is exactly why it's both warning-free and more honest. Unless you've got a real reason to want the (approximate) slider, I'd stay on cover.

If you ever do want to keep cover_position, you can silence the warning by making the template defensive -- {{ value_json["position"] | default(none) }}, or wrap it in {% if value_json.position is defined %} -- so it just skips the position-less messages instead of erroring. But since both give you the same real control, warning-free cover is the cleaner pick.

-- Sam

[Simchon]

Ok, so here is the cover-based external converter for this panel.
HA users should control the shutter/cover using the "cover" entity, but read the "sensor" entity for the state: OPEN/CLOSE/STOP:

const tuya = require('zigbee-herdsman-converters/lib/tuya');
const exposes = require('zigbee-herdsman-converters/lib/exposes');
const e = exposes.presets;
const ea = exposes.access;

const definition = {
    fingerprint: [
        {
            modelID: 'TS0601',
            manufacturerName: '_TZE200_rgeapp2c',
        },
    ],
    model: 'TS0601_rgeapp2c_panel',
    vendor: 'Tuya',
    description: 'Semicom Tuya touch panel (2 switches + 2 shutters)',
    fromZigbee: [tuya.fz.datapoints],
    toZigbee: [tuya.tz.datapoints],
    onEvent: tuya.onEventSetTime,
    configure: tuya.configureMagicPacket,
    
    exposes: [
        // Expose Switches to Home Assistant
        e.switch().withEndpoint('s1'),
        e.switch().withEndpoint('s2'),
        // Expose Shutters/Covers to Home Assistant
        e.cover().withEndpoint('c1'),
        e.cover().withEndpoint('c2'),

        // Declare the state already published, so HA creates a sensor for it
        e.enum('state', ea.STATE, ['OPEN', 'STOP', 'CLOSE']).withEndpoint('c1'),
        e.enum('state', ea.STATE, ['OPEN', 'STOP', 'CLOSE']).withEndpoint('c2'),
    ],
    endpoint: (device) => {
        return {'s1': 1, 's2': 1, 'c1': 1, 'c2': 1};
    },
    meta: {
        multiEndpoint: true,
        tuyaDatapoints: [
            // --- LIGHTS / SWITCHES ---
            [101, 'state_s1', tuya.valueConverter.onOff],
            [102, 'state_s2', tuya.valueConverter.onOff],
            
            // --- SHUTTERS / COVERS ---
            // Cover 1 (DP 1 for state/control, DP 2 for position)
            [1, 'state_c1', tuya.valueConverterBasic.lookup({'OPEN': tuya.enum(0), 'STOP': tuya.enum(1), 'CLOSE': tuya.enum(2)})],
            //[2, 'position_c1', tuya.valueConverter.coverPosition],
            
            // Cover 2 (DP 4 for state/control, DP 5 for position)
            [4, 'state_c2', tuya.valueConverterBasic.lookup({'OPEN': tuya.enum(0), 'STOP': tuya.enum(1), 'CLOSE': tuya.enum(2)})],
            //[5, 'position_c2', tuya.valueConverter.coverPosition],
            
        ],
    },
};

module.exports = definition;

I am also attaching here the alternative cover_position-based external converter, in case someone finds it useful:

const tuya = require('zigbee-herdsman-converters/lib/tuya');
const exposes = require('zigbee-herdsman-converters/lib/exposes');

const e = exposes.presets;
const ea = exposes.access;

const definition = {
    fingerprint: [
        {
            modelID: 'TS0601',
            manufacturerName: '_TZE200_rgeapp2c',
        },
    ],
    model: 'TS0601_TZE200_rgeapp2c',
    vendor: 'Tuya',
    description: 'Semicom Tuya touch panel: 2 switches + 2 shutters',
    fromZigbee: [tuya.fz.datapoints],
    toZigbee: [tuya.tz.datapoints],
    onEvent: tuya.onEventSetTime,
    configure: tuya.configureMagicPacket,
    options: [exposes.options.invert_cover()],
    exposes: [
        // Expose Switches to Home Assistant
        e.switch().withEndpoint('s1'),
        e.switch().withEndpoint('s2'),
        // Expose Shutters/Covers to Home Assistant
        e.cover_position().withEndpoint('c1').setAccess('position', ea.STATE_SET),
        e.cover_position().withEndpoint('c2').setAccess('position', ea.STATE_SET),
        
        // Declare the state already published, so HA creates a sensor for it
        e.enum('state', ea.STATE, ['OPEN', 'STOP', 'CLOSE']).withEndpoint('c1'),
        e.enum('state', ea.STATE, ['OPEN', 'STOP', 'CLOSE']).withEndpoint('c2'),
    ],
    endpoint: (device) => {
        return {'s1': 1, 's2': 1, 'c1': 1, 'c2': 1};
    },
    meta: {
        multiEndpoint: true,
        tuyaDatapoints: [
            // --- LIGHTS / SWITCHES ---
            [101, 'state_s1', tuya.valueConverter.onOff],
            [102, 'state_s2', tuya.valueConverter.onOff],
            
            // --- SHUTTERS / COVERS ---
            // Cover 1 (DP 1 for state/control, DP 2 for position)
            [1, 'state_c1', tuya.valueConverterBasic.lookup({'OPEN': tuya.enum(0), 'STOP': tuya.enum(1), 'CLOSE': tuya.enum(2)})],
            [2, 'position_c1', tuya.valueConverter.coverPosition],
            
            // Cover 2 (DP 4 for state/control, DP 5 for position)
            [4, 'state_c2', tuya.valueConverterBasic.lookup({'OPEN': tuya.enum(0), 'STOP': tuya.enum(1), 'CLOSE': tuya.enum(2)})],
            [5, 'position_c2', tuya.valueConverter.coverPosition],
            
        ],
    },
};

module.exports = definition;