Unit report: protocol 3.40 indoor unit, all special modes NAK'd over S21

[FrAllard]

First, thanks for this component. It works well and the 60 s debug dump made diagnosing my unit straightforward.

Reporting as requested in the Contributing section: a protocol 3.40 indoor unit that answers every readout query but refuses both extended write commands.

Setup

• Indoor unit: FTXM12WVJU9, manufactured 2025-12, made in Thailand,
  R32 / A2L, 208-230 V single phase. Installed in North America in 2026.
• Connected to the free S21 port. The unit also has Daikin's own WiFi
  module on a separate link, which stays connected and does not interfere.
• Custom ESP32-S3 board, esp-idf framework, ESPHome 2026.9.0
• Component at commit 30239f599d870c0e7a97ad7db1bde6b17e9339f0
• UART: GPIO5 TX / GPIO4 RX, both inverted, 2400 8E2

60 s debug dump

Ready: 3F  Protocol: 3.40  ModelV0: FFFF  ModelV2: 1348  ModelV3: C008
 G8: 0200  GY00: 0430  Ver: 20008E01  Rev: EC970D2F
 Fan: Y  VSwing: Y  HSwing: Y  MI: N  Humidify: 00
 Dry: Y  Demand: N  Powerful: N  Econo: N  Streamer: N
 G2: 3C:3B:00:80  GK: 31:3B:3D:30  GU00: 31:30:30:30:30  ActiveSrc: Rg  PowerfulSrc: G6
 Mode: COOL  Action: COOLING  Setpoint: 24.0C  Target: 24.0C  Inside: 22.5C  Coil: 10.0C
 Cycle Time: 2912ms  UnitState: C  SysState: 44
 Enabled: F1,F4,F5,F6,F7,FR,RG,RH,RI,RL,RN,RX,Ra,Rb,Rd,Re,Rg,RzB2,RzC3
   Nak'd:
 Static: F2,F8,FC,FK,FU00,FU05,FY00,FY10,FY20,VS000M

No readout query was NAK'd. Every sensor and binary sensor I enabled reports plausible values, including power and the three energy counters unlocked at 3.20.

What works and what does not

Command	Carries	Result
D1	power / mode / setpoint / fan	accepted
D5	swing + humidity modes	accepted
DR	vertical swing angle	accepted
D6	the special modes bitfield	NAK
D7	demand + econo	NAK

The climate entity is fully functional: on/off, all six modes, setpoint, all seven fan speeds, and swing in both axes.

Every special mode switch reverts within one or two poll cycles. The log line is always the same:

W [daikin_s21:827]: NAK for D6

Econo fails the same way through D7.

The part that may interest you

GU00 reads 31:30:30:30:30, i.e. the ASCII string "10000", so support.powerful, support.econo and support.streamer are all correctly computed as false. That matches the unit's behaviour and your capability decoding looks right for this model.

But GK reads 31:3B:3D:30 ("1;=0"), which sets both:

• support.ac_led = GK[0] & 0x01 → 0x31 bit 0 → true
• support.motion_detect = GK[1] & 0x08 → 0x3B bit 3 → true

So the unit declares the LED and motion-sensor features as supported, yet writing them NAKs, because they ride in the same D6 frame as the modes it does not support. The refusal is at the frame level, not per bit — I confirmed this by toggling only the LED switch, whose support bit is set, and getting NAK for D6.

If that is worth distinguishing, it means ac_led / motion_detect from GK cannot be used on its own to decide whether D6 is writable on a unit. On mine, GU00 is the only reliable gate, and it gates the whole frame.

Two smaller observations

1. dump_config() never logs the brightness select.
In components/daikin_s21/select/daikin_s21_select.cpp:

void DaikinS21Select::dump_config() {
  LOG_SELECT("", "Humidity", this->humidity_select_);
  LOG_SELECT("", "Vertical Swing", this->vertical_swing_select_);
}

brightness_select_ is missing, so a configured brightness select never appears in the boot enumeration. It is instantiated and does work — it just looks absent. This briefly led me to think my YAML had not applied.

2. The model name comes back empty.
FU05 (ModelName) is enabled at 3.40 and appears in the Static list, but the model text sensor publishes an empty string. ModelV0 is FFFF, ModelV2 is 1348, ModelV3 is C008. I have not dug further; happy to run debug queries if you want to chase it.

One suggestion, take it or leave it

Since the component already computes support.powerful, support.econo, support.streamer and support.demand, it could log a warning at boot when a switch or number is configured for a feature the unit has declared unsupported. That would have pointed me straight at GU00 instead of at my own wiring, which is where I started looking. A one-line hint in the README next to the switch list would do the same job.

I am happy to run any debug query or patched build on this unit. It answers everything, so it may be a useful reference for the higher protocol versions you do not have on hand.

[FrAllard]

Follow-up on my unit (FTXM12WVJU9, protocol 3.40), this time a readout issue.

FU04 (EnergyConsumptionClimateModes) answers on this unit, so it is never NAK'd and never lands in the Nak'd: list — but both fields come back as FFFFFFFF, which I read as "no data" rather than a measurement.

handle_state_energy_consumption_climate_modes() passes it straight through:

this->energy_.cooling.add_sample(bytes_to_num(payload.first(8), 16));
this->energy_.heating.add_sample(bytes_to_num(payload.subspan(8, 8), 16));

and the sensor divides by 10, so Home Assistant receives

4294967295 / 10 = 429496729.5  ->  float32  ->  429496736 kWh

for both energy_cooling and energy_heating. That is what shows up in the dashboard, and it poisons the long-term statistics, which then need to be deleted by hand in HA.

Worth noting that FM (EnergyConsumptionTotal) is fine on the same unit — it reports 20.0 kWh, which is believable for a machine installed a few weeks ago. FX60 (UnitPower) is also fine at 150 W with the compressor at 24 Hz. So it really is only the per-mode pair that has no backing data here.

Would it make sense to discard an all-ones sample in that handler, the way an unsupported query is discarded? Something like treating 0xFFFFFFFF as "no reading" and not calling add_sample() at all, so the sensor simply never publishes instead of publishing a sentinel.

I have disabled both sensors in my YAML for now. Happy to test a patch.

[asund]

Thanks! For some reason github's notifications don't go to my phone and I miss them unless I manually check so sorry about the delay.

Without a range of hardware to test against I've tried to err on allowing features to be configured rather than enforcing detected features. Daikin compounds this by reporting unit capabilities that might not be controllable over S21 (like your D6 issue). Perhaps GU00 is protocol support and GK is hardware support? I've wanted to make some of the capabilities detection and registering components more dynamic, but it feels like a bit of a chore in ESPHome at my skill level. The system would need to do a few rounds of communication with the unit in the setup phase before the components are exposed to HA. Though I think some indication where there's no support detected at runtime would be beneficial and spare users some debugging efforts.

I'll happily make some changes for you:

1. Brightness select dump was an oversight, I'll add that.
2. Model name issue appears to be known: [Documentation] S21 protocol: new findings  revk/xESP32-Faikout#408 (comment). I can return "Unsupported" when all spaces is read out.
3. All ones values were seen for other fields when unsupported, it seems reasonable to not publish or publish NaN for the energy sensors when this is the case.

I'll add your unit to the Faikout wiki and think more on how to best support reporting when there's a configuration/capabilities mismatch...

[asund]

I have a branch at https://github.com/asund/esphome-daikin-s21/tree/fixes/frallard with those listed changes.

[asund]

While I've got you here with a newer unit, I have this issue #196 where I'm trying to better sequence the vertical swing angle setpoint select. If you were to enable some debug text sensor queries (FR for raw vertical setpoint mode, RM for vertical angle internal target) and run through a couple setpoints while logging that could help with that. Right now it's a dumb timeout, so I'm trying to observe anything that would allow me to say the operation is complete.

[FrAllard]

Disclosure first. I am working with an AI assistant on this one. The hardware is mine and I ran every test myself on my own unit, so the logs and the observed behaviour are real and I can rerun anything you ask. But the protocol decoding, the local patch and the write-up below are assisted, and a good part of it is frankly over my head. So please treat the conclusions as something to verify rather than take on trust, and if you spot me asserting something wrong, say so bluntly — it will not offend me. The analysis took a couple of wrong turns before further testing settled them, and I kept one of those below rather than quietly dropping it, since the false reading is informative in itself.

---

Tested fixes/frallard on my FTXM12WVJU9 (protocol 3.40). The brightness select now appears in the boot enumeration, so that fix is confirmed.

For the rest I patched your code locally to see the responses. RM turns out to be far more useful than you feared, and DR is a dead end on this unit.

I enabled your response logging

debug_comms only logs Tx:, so there was no way to see what the unit answers. The receive-side logging already exists in s21.cpp — it is just unreachable:

static constexpr std::array debug_commands{""};
const bool is_debug = this->debug_protocol && (std::ranges::find(debug_commands, tx_str) != debug_commands.end());
...
if (/*this->debug_protocol ||*/ is_debug) {
  ESP_LOGD(TAG, "ACK: %" PRI_SV " -> %s %s", ...

debug_commands is empty, so the condition is always false. I changed both guards to this->debug_comms || is_debug and relabelled the line Rx: to pair with Tx:. Everything below comes from that build, and that one-line change is what made it possible.

Decoding

Payloads are reversed ASCII with the sign last: 271+ is +172, 410- is -014. Verified against the component's own sensor — every RN value matches swing_vertical_angle exactly, sample for sample, and RH returned 512+ then 012+ while the inside temperature went 21.5 to 21.0.

RM is the setpoint angle. RN is the measured angle.

RM tracks the sweep target, and it is fast

This is the part relevant to #196. Vertical swing enabled from Home Assistant, then left alone for 80 seconds:

20:29:54.396  Tx: D5 1?00
20:29:54.447  Rx: D5 ->
20:29:54.559  RM = 821+  ->  128      target = bottom of sweep
20:29:55.802  RN = 362+  ->  263
   ... descending ...
20:30:06.539  RN = 821+  ->  128      measured reaches target
20:30:11.441  RM = 972+  ->  279      target flips, 4.9 s later
20:30:12.679  RN = 841+  ->  148
   ... ascending ...
20:30:23.494  RN = 972+  ->  279      measured reaches target
20:30:28.351  RM = 821+  ->  128      target flips, 4.9 s later
   ... and so on ...
20:30:40.329  RN = 128   (reached)
20:30:45.225  RM = 279   (flip, 4.9 s later)
20:30:57.207  RN = 279   (reached)
20:31:02.119  RM = 128   (flip, 4.9 s later)

So during a sweep, RM holds the endpoint the louvre is travelling toward, RN converges on it, and RM flips to the other endpoint after a dwell. Four consecutive cycles, with the flip coming 4.9 s after convergence every time, and a half-period of 16.9 s that varied by less than 40 ms across the four.

Contrary to what you expected, RM on this unit refreshes promptly — every poll, same as the measured angle — and RM == RN is a clean, unambiguous arrival signal. If v2 units behave like this, polling RM and comparing is a solid completion detector.

-14 shows up as a "no setpoint" value when the louvre is released into free travel.

A false lead, kept for the record

A first pass at the data looked like 0x3F (?) appearing in F5 and FR was an "operation in progress" marker, which would have been a cheap completion signal. It is not, and the clean run shows why: the component itself sends ? in the command payload — Tx: D5 1?00 — and the unit simply reflects it back. FR reads ?000 for the entire time vertical swing is active and returns to 0000 the moment D5 0000 clears it. So FR[0] == '?' means vertical swing is on, not that something is in motion.

DR is acknowledged and ignored, in every state

I tested the hypothesis that the unit might only accept a setpoint while the louvre is already moving. It does not.

Parked and idle, from an earlier run:

Tx: DR 4000 34:30:30:30
Rx: DR ->

Empty ACK, no NAK, no timeout. Over the next 20 polling cycles FR stayed 0000 and RM stayed 972+, one distinct value each across 42 samples, and the louvre did not move.

Mid-sweep, from the clean run:

20:31:12.005  select 'Position du volet' = Middle
20:31:12.032  Tx: DR 3000 33:30:30:30
20:31:12.084  Rx: DR ->

Same empty ACK, and the louvre did not seek the setpoint.

Swing already off, 26 seconds later:

20:31:38.473  Tx: DR 1000 31:30:30:30
20:31:38.524  Rx: DR ->

Nothing at all. No RM change, no RN change, for the remaining 36 cycles.

So on this unit DR is a no-op in all three states, even though FR answers and louvres.command_support is therefore set.

A side effect that makes things worse, not neutral

Worth flagging on its own. When I selected Middle during the sweep, the component followed the DR with its own D5 0000 to clear basic swing, as the code intends:

20:31:12.032  Tx: DR 3000     (ignored by the unit)
20:31:14.720  Tx: D5 0000     (honoured by the unit)
20:31:14.786  Rx: D5 ->
20:31:15.353  FR = 0000

D5 works on this unit, so the swing I had actually stopped. The louvre parked at 128, wherever the sweep happened to be, and RM snapped to 128 to match. Both stayed there for the remaining 36 cycles.

Net effect for the user: picking a vertical position on a unit that ignores DR silently destroys the swing they had and parks the louvre at an arbitrary angle, while Home Assistant shows the position they asked for. Selecting Top afterwards then did nothing at all, since swing was already off.

The contrast with the brightness select on the same platform is instructive. That one writes the LED bits through D6, which this unit NAKs, and it reverts to its real value on the next poll — I set it and it goes straight back to High. So the failure is visible there. Position du volet is the odd one out: FR keeps reporting 0000 the whole time, yet the select holds whatever was asked for. A user gets honest feedback from one select and a silent lie from the other.

If detecting an unresponsive DR is feasible — the measured angle not moving within the existing timeout, say — it would be worth not clearing basic swing until the setpoint is known to have been taken.

The debug query text sensors never publish

Separate issue, and it is why I needed the Rx: patch at all.

With queries: [FR, RM] both sensors are created and both queries are polled every cycle, but neither ever publishes. I instrumented the loop:

PATCH loop: 'FR' lu='0000' etat='0000' -> unchanged, nothing published
PATCH loop: 'RM' lu='972+' etat='972+' -> unchanged, nothing published

From the first loop iteration I could observe, sensor->state already equals the computed value, so the if (sensor->state != current_state) guard never fires. That held for all 42 iterations, and there is not a single text sensor state in the whole log. The values are correct internally — the Rx: lines prove it — they just never reach Home Assistant.

I diffed text_sensor/daikin_s21_text_sensor.cpp against your pinned commit before suspecting the branch; it is byte-identical, so whatever is happening is upstream of the publish path.

Happy to run anything else. This unit is on my bench and answers every query.

[FrAllard]

Follow-up. I think I found why DR does nothing on my unit, and the fix may be smaller than it looks — the fallback you already wrote works fine here, it just never gets a chance to run.

Same disclosure as before: AI-assisted analysis, my hardware, my tests, please verify rather than trust.

The root cause is the support detection

handle_state_vertical_swing_mode():

this->vertical_swing.active = s21_to_vertical_swing_mode(payload[0]);
this->louvres.command_support = true; // TODO move check to initialization

command_support is set because FR answered, not because the unit does anything with DR. But the Faikout wiki documents FR byte 0 = 0 as "default position (also reported by units without manual angle setting)" — which is what my unit reports whenever swing is off. With swing on it reports ?, as documented.

My IR remote confirms it from the other side: it only has swing on/off, no fixed vane positions. So this indoor unit has no manual angle setting at all, yet it answers FR, so it is detected as having command support, and each of the three DR writes I tried was acknowledged and dropped.

Forcing the fallback makes it work

I changed that one line to false locally and configured the angle presets to match my unit's measured range. The existing swing-and-pause path then does exactly the right thing:

21:07:38.587  Vertical setpoint control set to 130
21:07:38.658  Tx: D5 1?00
21:07:39.122  RN = 771+  -> 177
21:07:40.674  RN = 751+  -> 157
21:07:42.208  RN = 731+  -> 137
21:07:43.745  RN = 821+  -> 128
21:07:43.748  Vertical setpoint control successful, terminating at 128
21:07:43.820  Tx: D5 0000

Swing starts, the angle is watched, the louvre stops near the setpoint. It physically works, and the entity reflects reality instead of a value the unit ignored.

So the mechanism is all there. From the outside the missing piece looks like the support detection rather than anything in the fallback itself, though you will know better than me whether that holds everywhere.

I did not try to fix the detection myself, since your TODO suggests you already have a direction in mind. If it helps: a write that is never reflected in FR within the existing confirm countdown would be a natural place to latch command_support = false and fall back, with no new state needed. Happy to implement and test whatever you prefer — I have a unit that shows the problem, so I can turn a patch around quickly.

Two scaling problems the fallback then runs into

My unit reports vane angles on a different scale from yours. The wiki's examples are SM780+ = 87 and SN510+ = 15, and your defaults are 5 to 87. Mine sweeps 128 to 279 and reaches 404 when parked. Probably tenths of a degree, which would be a believable 12.8 to 27.9 for a wall unit.

The preset validator caps at 255. ANGLE_SEPOINT_VALIDATOR is cv.uint8_t, so I cannot configure a setpoint anywhere in the upper part of my unit's travel. I had to keep all five presets below 255.

SwingPauseTolerance{5} is absolute, and too tight here. At this scale the louvre moves about 20 units between polls, so landing within ±5 is luck. Out of three setpoints:

Target	Nearest samples	Result
130	137, 128	stopped, Δ2
190	185	stopped, Δ5
250	257, 244	never stopped, Δ7 and Δ6

Two out of three landed; the third sailed past twice. A tolerance derived from the observed travel per poll, or simply from the spacing between presets, would behave the same on your units and work on mine.

Logs for any of this on request, and I can rerun anything.

[asund]

Wow, thank you! By the way, https://codeberg.org/RevK/ESP32-Faikout/wiki/S21-Protocol is our current understanding of the protocol, now that you're getting into it. D commands respond with a simple ACK, the associated F query returns the G response. So the findings about DR are expected, whether or not they are taken by the unit and returned in GR is the question.

A brief summary for myself or for your objections to my understanding:

• I can use RN converging on RM as the vertical setpoint completion signal, at least on units that support DR. This is a good solution and a relief. I half implemented it previously but my own unit's RM results made me discard it.
• Your unit "supports" issuing commands over DR but they're not accepted. I think the D5 sent right afterwards could be a bug in my code that's causing operation to break. I have no way to test DR related stuff and recently added this support and haven't received any feedback. I shouldn't be sending D5 in this case, instead allowing DR to do its job and being careful about how the values are interpreted during this time (don't trust F5 when louvres.enabled, etc.). The worst case is what you assume, the command is supported but it doesn't do anything, breaking detection. I will hope that it's just a bug and investigate that first.
• The difference between the brightness (or most other unsupported commands) and the vertical setpoint select is that I have code that interprets the two swing sensors and provides the user with synthetic results so I can try to hide the commands I'm making under the hood (leaving horizontal swing showing as true, even if the unit is seeking to a new vertical setpoint and then restoring the horizontal enabled state). This code has to be bug free in order to work correctly! So I will try to work the bug out and then let's see if this behaves the way it was intended.
• Gating publishing on a value being changed means the debug Text Sensor components aren't displayed in HA. I create those sensors on the fly in code and could have missed registering them in a way where the current state of everything is dumped to Home Assistant when it first connects. I can look into this. The regular text sensors seem to populate even though they're showing static information?
• Some units have finer values for these angles. I agree with your assessment that it's probably a 10x scale applied to them. The problem for me is detecting when this is the case, though I could make assumptions about the range of values. If I can fix DR, the setpoint angles you're configuring won't be necessary, but I can update the validator to match the wider angle measurement type.
• I'm curious about "-14 shows up as a "no setpoint" value when the louvre is released into free travel." What did you mean by this? Usually the oscillating mode is what I think of, but your example above shows RM with the real value it's commanding to its stepper motor control loop. When switching operation mode I see out of range angles as the louvre is commanded closed on off or initially opens when powered on. Sometimes it makes sense to me -- parking it closed for off looks like a real angle, but sometimes my sensor reports -129 even though the range of motion doesn't permit that. is for me Is this what you mean? I seem to recall other users reporting different out of range angles so it didn't feel like a sentinel value Daikin uses. I've thought Daikin could be doing something internally during this time that results in integer rollover being incorrectly formatted for the RN response, but haven't seen a good pattern to figure out what that might be.
• Another thing I've been thinking about recently: Localization. You must find having to choose "Middle" and the like from us English devs tedious and I have other users from over the world and I'd like to find a way to provide translations for things like the Select options... I'll look into this.

Anyways, thanks again! Plenty to go with on this. I seem to be in a period where I have some time to work on the project so will get started on this list in the next little while.

[FrAllard]

Thanks for going through all of it. On -14: you are right to push back, and my answer is that I overstated it. Calling it a "no setpoint" value was an inference from context, not something I established, and I should have written it that way.

Here is all the evidence I actually have. RM returned 410- (reversed, -014) exactly twice, in one run:

20:22:21.414 — RM goes from 279 to -14. Then 0.16 s later F1 changes from 13HA to 03MA, first character 1 to 0, so the unit is powering off. Rg drops from 1 to 0 shortly after and the climate entity goes OFF. This one fits the wiki note that these values can go negative when the unit is off and the louvre is closed.

20:22:55.448 — RM goes from 404 to -14 while the unit is running in cool. Vertical swing had been switched off at 20:22:41.737 and RN was descending from 404 through 365 to 330. This one does not fit the "unit off" explanation, and I have no account of it.

Two samples, one of which contradicts the reading I published. So: no, I cannot support "sentinel".

Your 10x idea probably dissolves the question

If the finer scale is a 10x factor, then on a unit like mine -14 is -1.4° and the -129 you have seen elsewhere is -12.9°. Both are unremarkable angles for a louvre at or slightly past closed. There would be nothing to explain and no Daikin sentinel to look for — the numbers only look absurd when read against units that report whole degrees.

That is consistent with the rest of my readings. My unit sweeps 128 to 279 and parks at 404, which on a 10x scale is 12.8° to 27.9° with a 40.4° park. Plausible for a wall unit. At 1x those same numbers are impossible.

I am not claiming this is settled either — it is a hypothesis that happens to fit, and it is yours, not mine.

A test that would settle the scale

If it is useful, I can power the unit off, let the louvre close fully, and capture RM and RN at rest, then power it back on and log the complete travel. That gives the true minimum and maximum of the scale on this unit, including however far negative it really goes when closed.

If the closed position lands somewhere sane on a 10x reading and the full travel spans a believable physical range, the 10x factor stops being a guess. And if other users ran the same short capture, the minimum at rest might be the per-unit discriminator you need, since a 1x unit and a 10x unit should separate cleanly on that one number.

Say the word and I will run it. Same for anything else once you have looked at the D5-after-DR bug — I would rather wait for that than keep poking at the fallback, since you may be right that DR never had a fair chance here.

Unrelated: the setpoint step looks like it could be 0.5

Different subject, and no rush on it.

SETPOINT_STEP is 1.0F, commented "Daikin setpoint granularity". But the setpoint byte in F1 carries half degrees on my unit. Three samples: H = 22.0, M = 24.5, N = 25.0, which is (byte - 28) / 2. The 24.5 was not something I contrived — the unit was already sitting at it, set from its IR remote, before I looked.

Worth heading off the obvious objection, since this is a North American unit: it is configured in Celsius, and these are real Celsius setpoints rather than an artefact of whole-degree Fahrenheit being converted. The values land exactly on the 0.5 °C grid. A Fahrenheit-native setpoint would show up as 22.2 or 22.8, never as a clean 24.5.

The constant does double duty: it is both the step advertised to Home Assistant and the rounding applied to the setpoint before it is written. So a visual: override in YAML would not help on its own — HA would offer 24.5 and the component would round it away before the command went out.

I changed it to 0.5F in my local copy and flashed it. Home Assistant now offers half degrees, I have a 20.5 setpoint running, and the unit reports it back. No other change.

I have no idea whether every unit tolerates this — plenty of them may only want whole degrees, and you would know. If some do and some do not, this looks like something that belongs with the other per-unit traits rather than as a compile-time constant. Happy to leave it as my local patch if it is not worth the complexity.

[asund]

Yes, I had been thinking of selectively applying the scaling by 10 based on the readout value, though after checking with my unit the -129 I mentioned is actually +129 when the unit is parked in off mode, which makes sense for the angle of the blades visually. 129 would be 12.9 for you, a possible angle when the unit first powers on and exercises the range of motion before settling in. So a rule based on readout value doesn't look possible

I think I could just supply instructions to do the scaling with a filter in YAML for this one, making the only other change increasing the number of decimal places to 1. Assuming I find and solve that preset setpoint bug so the fallback mode angles aren't required to also support 10x scaling... I'll focus on that one first.

The range of your angles do look outside of what Daikin publishes, but since they have two blades at different ranges they're probably gearing the output value being read by the sensor mechanically:

[asund]

Regarding the F1 value, that is another thing to investigate. I'm not sure if I looked at that too much after forking this project, that support was just so fundamental that the only changes I made was refactoring without changing the logic. My IR remote only offers 1 degree steps so I took that as normal, despite the half degree steps documented in the wiki.

[asund]

I will try to tackle the suspected bug under issue #196. Though the angle measurement scaling means I'll leave a decent tolerance for detecting the two angles being the same, just in case there's an internal deadband that stops motion within e.g. a degree (which would be 10 sensor increments).