Style binding: implicitly assign 'px' as the default unit for numeric values for certain css properties

What problem does this feature solve?
When assigning values to a CSS property via style binding like

or using the shorthand syntax...

this will actually not gonna work because we need to explicitly set the unit:

or via interpolation...
    <div class="d-inline-block" :style="{width : `${width}px`}">

Now our code becomes more verbose. Combining all the number of occurrences of such binding, it's becoming ridiculous.
I'm not sure if currently there is an elegant solution for this, but if there is. It would be also good if it is referenced in in the docs.
In React, this is the default behavior. It will add 'px' if the unit is not specified.
What does the proposed API look like?
For common css properties like width and height, having vue implicitly assign 'px' to the value it would definitely make our code much more cleaner.
This code...

will be interpreted as:

TBH I'm not a fan of this feature. A CSS property can accept multiple value types and even it's “unitless” today doesn't mean it will stay “unitless” forever, and vice versa. As the language evolves,  maybe someday a “unitless” property can take length units, or those accept length units can take “unitless” values. If a property use to not accept “unitless” values and later changed to accept them, we would never know the true semantics behind a number if we had supported appending px to it by default.

Hi @Justineo,
I see your point, but I think you're a little bit exaggerating such concern. We know CSS' implementation in relation to the units of values of css properties hasn't changed that much between versions. Take the width or height for example, ever since the birth of CSS, it hasn't changed much. It didn't go unitless.
And also, I am certain that some properties wouldn't go unitless, particularly those properties where length are involved like the height, width and border for example. As far as CSS maturity is concerned, I'm pretty much sure that we won't be seeing something like height: 1 or opacity: 1em in the future.

I'm not a fan of this either, it means we have to keep another list of unitless properties and keep it up to date, and it has to be added at runtime too because a property name could be dynamic

Hi @posva,
I think we we don’t necessarily need to list all unitless or non-unitless properties. We could just list the commonly used properties in real world scenarios. Like the height and width, there are cases where we assign these properties via javascript.

Unfortunately, that wouldn't be consistent and confusing to users

Hi @posva ,
Yes, you are right.

I think this would be doable with a sort of feature-detection solution. For example, if a value of type "number" were passed, then during normalization a one-time check is done to see whether the property in question supports unitless values.
At least in Chrome, if a value isn't allowed to be unitless, it won't get set:
tmpDiv = document.createElement("div")
tmpDiv.style.width = 20
console.log(tmpDiv.style.width) // output: ""

This should allow Vue to maintain high performance in this area due to the solution's opt-in nature. If a developer never passes a number type, then they'll never encounter that branch.

As you can see, feature is already included in Vue 3:
https://github.com/vuejs/vue-next/blob/eaf414f06366b413e36a688749a6524687b952d7/packages/shared/src/domAttrConfig.ts#L44-55
Although I mentioned this is theoretically not a safe move, the reality is that this feature already exists in React and we would have to take this into account when trying to evolve CSS, to prevent conflicts with the most popular JavaScript frameworks.
Maybe we can back port this into 2.7 after 3.0 and the companion libs are fully ready. But we still have to maintain a list because feature detection doesn’t work on the server side.

As you can see, feature is already included in Vue 3:
https://github.com/vuejs/vue-next/blob/eaf414f06366b413e36a688749a6524687b952d7/packages/shared/src/domAttrConfig.ts#L44-L55
Although I mentioned this is theoretically not a safe move, the reality is that this feature already exists in React and we would have to take this into account when trying to evolve CSS, to prevent conflicts with the most popular JavaScript frameworks.
Maybe we can back port this into 2.7 after 3.0 and the companion libs are fully ready. But we still have to maintain a list because feature detection doesn’t work on the server side.

Yes, that's what I'm saying ever since I started this discussion. React has been implementing it, so why shouldn't we?
Anyway, it's really cool seeing this getting pushed despite the tons of dislikes. 😅
I'm looking forward to Vue 3.0. ❤


Update portfolio

Coverage remained the same at 86.018% when pulling<PHONE_NUMBER>2c050d02a32273e74e2d41829dc680 on JYL123:updatePortfolio into 4e254ba849a36c9997aafad8c841005616599174 on CS2103AUG2017-W11-B1:master.


Change the background color of the popup

Description

The background color of the popup matches with that of the footer due to which it is hard to notice the popup.
Reproduction

 Click on the image to copy the url.

 The popup should appear at the bottom of the page.

 It is hard to distinguish due to the background color of the footer and popup.

Expectation

The popup should be easily noticeable.
Screenshots

https://share.getcloudapp.com/X6udONk5#
Resolution

[x] I would be interested in resolving this bug.

Hey @zackkrida, is this a valid issue? If so, then I will fix this.


Project migration to SBT to support cross build (Scala 2.11 and 2.12)

Addresses #5 .

We need to run the checks in CircleCi.

Closing and reopening to check CI setting.

Shall we add version.sbt as well? To work with release plugin smoothly I had to move the version out of build.sbt in spark-state-tools project, and here build.sbt is also missing.
https://github.com/HeartSaVioR/spark-state-tools/blob/master/version.sbt
The version would be 0.2.0-SNAPSHOT.
Thanks!

Oh I missed that, sorry. I'll add it now.

Superb! I'll manually test for the publish phase in local and merge this. Thanks!

You're more than welcome!

I've tested and looks to be working. Thanks!


Clamp arguments before initializing RGBA.

Any other places you would suggest RGBA arguments should be clamped?
The only place I'm not sure is the RGBA mix fn from m/IInterpolate that could also cause some issues. All the other color conversions make sure to clamp their values.

Hi @dimovich - thank you for this, but clamping during RGBA creation is actually undesirable and should only happen during conversions. The reason being is that float-based RGBA color channels could (and in some of my own projects indeed are) taking on values outside the 0..1 interval (e.g. for HDR). So the channels should only be clamped when converting to a format (like packed ints and most others) where the range is fixed... Sorry, I should have explained this in more detail on Discord...


Feature request: an updateStaticContext function

Thanks for making react-router 4, I'm really liking it so far. But I'm having trouble with one thing, and it affects compatibility with some tooling.
The issue is with staticContext. It's unusual (and a bit brittle) to pass a singleton object around to be freely mutated, and it causes all sorts of problems with static analysis. It's impossible to type-annotate cleanly. Even if I customise the type definition in the react-router flow-typed libdef I still have problems. It also breaks an ESLint rule that I'd prefer not to override.
It would be great if you could add a new item to the the standard server router context, updateStaticContext, allowing the user to pass a pure function to replace the static context without forcing them to mutate anything – typically by spreading the old object into a new one, Redux-style:
const NotFound = () => (
  <Route
    render={({ updateStaticContext }) => {
      if (updateStaticContext) {
        updateStaticContext(context => ({
          ...context,
          status: 404,
        }));
      }
      return
Not found
;
    }}
  />
);

You could keep staticContext around for those who prefer it, so this would only need to be a minor update. Would you consider adding this? If so I would be happy to PR.

That seems sensible.
One counter-thought: Could you set that function as a property in the staticContext? That would seem to serve the same purpose. You could even try to make a mini Redux and give it those kinds of semantics, which are type-able.

Good idea. I'll try that. Happy for you to close this, unless you want to add it formally to RR's API.


Codeunit 5522 Order Planning Mgt.

Please insert new Publisher in function InsertAltSupplyLocation
  TempReqLine."Quantity (Base)" := AvailableQtyBase;

  // S/NEW
  OnBeforeInsertTempReqLine(TempReqLine);;
  // E/NEW

  TempReqLine.INSERT;

Would passing TempReqLine by value be enough?

Please by VAR - thx


fix: type error with BufferStream.from

Hey,
I'm working on this on a separate branch - the current ts definitions are generated from the source code, I will be changing this shortly, but if you want this to work, instead of fixing this here, please see if you see the same problem in jsdoc in scramjet-core/lib/buffer-stream.js

Done in scramjet-core. Will be published with 4.28.1.


Counting CSS conditional comments?

Apparently DOM Monster is counting CSS conditional comments.
In my site the only comment is a hack for IE

And DOM Monster reports it as a regular comment.
Should DOM Monster ignore this kind of comment when counting?
If so, how?
Regards.

I think it is easy possible, we could track down the conditional comments and remove it from counting. But i don't know if Thomas like the idea behind this.
Is this really needed?

Well, my point is:
Conditional comments are not "real comments" they are there with a programmatic purpose.
So IMHO they couldn't be counted as regular comments.
Should be counted in a separate comment category at least.


Task 12 code example errors

examples for running finsql.exe to filter out test objects are both faulty:
Database="<MyDatabaseName>,
Should be:
Database="<MyDatabaseName>",

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: b69c11d2-4915-8e2e-f38c-7bb1a3777bf9
Version Independent ID: 0028111c-4f1a-df24-0d47-48b7f6e6d98a
Content: Upgrade Application Code - Business Central
Content Source: dev-itpro/upgrade/Upgrading-the-Application-Code.md
Service: dynamics365-business-central
GitHub Login: @jswymer
Microsoft Alias: jswymer

Hi, thanks for your feedback. The typo will be fixed with the next doc refresh.


Initial testing

New features:

If any file in the rust-wrapper changes the bindings will be re-generated.
Add doctest framework for testing C++ code.
Move examples that were used for testing to their own tests.

:link: zboto Link

I need to update README with instructions on how to run the tests.


v5 without v4 .rebuild()

Basically I'm using a library, react-svg-pan-zoom, that places svg depending on the dynamic coordinates we give.
In this case, the v4 .rebuild() was to place the tooltip under the coordinates that it gave when hovering over the specific svg icon.
At the moment, with v5 the tooltip is updating the hover data but the tooltip box appears outside the svg icon and is always on screen, it doesn't just appear on the hover as before with v4.
Is there any way to trigger the tooltip like .rebuild() in v4?
v4:
const handleMouseOver = (e) => {
    setData(...);
    ReactTooltip.rebuild();
};

To insert Dynamic tooltip:
componentNode.setAttribute("data-tip", "");
componentNode.setAttribute("data-for", "tooltip");

React component:
<ReactTooltip
  id="tooltip"
  place="bottom"
  type="light"
  effect="solid"
  backgroundColor="transparent"
  getContent={() => {
    return (
      <Card
        mainComponent={data?.mainComponent}
        description={data?.description}
        value={value}
        machine={`${t("Machine")} ${id}`}
      />
    );}}
 />

v5:
componentNode.setAttribute("data-content", "");
componentNode.setAttribute("data-for", "tooltip");

<ReactTooltip
  id="tooltip"
  place="bottom"
  type="light"
  effect="solid"
  backgroundColor="transparent"
  content={
      <Card
        mainComponent={data?.mainComponent}
        description={data?.description}
        value={value}
        machine={`${t("Machine")} ${id}`}
      />
    }
 />

Do you mind building a (CodeSandBox)[https://codesandbox.io/s/react-new] or something similar so it's easier to understand the problem?
By the way, I've just realized some sections in the documentation say that data-tip was changed to data-content. That is incorrect, all new data-* attributes match data-tooltip-*, so for the content it would be data-tooltip-content. We'll be fixing the docs soon.
Also, this line doesn't do anything, since this isn't the way an anchor element is attached to a tooltip anymore.
componentNode.setAttribute("data-for", "tooltip");

Thanks for the last observation.
I'm working with svg icons where i only get the X and Y when i handle with mouse hover.
With hover i can get the correct data from that icon but the tooltip don´t have the trigger to update the X and Y tooltip on real time. The tooltip keep shows always in the same place of the screen, even with the correct data.
With .rebuild() trigger it worked fine.

Are you referring to the effect prop available in v4?
https://reacttooltip.github.io/react-tooltip/

Unfortunately, v5 launched without the float effect implemented, so right now we only have the old solid effect, which means the tooltip is fixed in place above the anchor element, but we are already working on that feature (#861).
We also accept contributions, if you'd be willing to help out. #861 already has the basics of how we're planning on doing it.

No, effect is ok in my side. It works with solid or float.
Is something similar to this situation:
https://stackoverflow.com/questions/62043514/react-tooltip-doesnt-show-on-conditional-render

Then I don't quite understand. The StackOverflow question doesn't seem related to what you described.
It would really help if you could post some sample code of what you're trying to do with v5, or at least a working example with v4, so I can understand what you're trying to accomplish.

Working example with v4 is on my first post.
const handleMouseOver = (e) => {
    setData(...);
    ReactTooltip.rebuild();
};

excerpt of code from the function that build dynamic x and y with the JS element created on that moment:
(...)
componentNode.setAttribute("data-content", "");
componentNode.setAttribute("data-for", "tooltip");
componentNode.setAttribute("x", `${data.xAxis}`);
componentNode.setAttribute("y", `${data.yAxis}`);
(...)

<ReactTooltip
  id="tooltip"
  place="bottom"
  type="light"
  effect="solid"
  backgroundColor="transparent"
  getContent={() => {
    return (
      <Card
        mainComponent={data?.mainComponent}
        description={data?.description}
        value={value}
        machine={`${t("Machine")} ${id}`}
      />
    );}}
 />

With this way on v4 react tooltip is working fine on my side.

Hi @ivansilvestre, I believe what @gabrieljablonski asked, is a live example and I agree.
Can you please create a simple example on https://codesandbox.io/ that reflects what you want, please?
I read the comments and I believe you're thinking about v4 .rebuild(), but the .rebuild() only triggers a re-render of react-tooltip in v4 (basically a workaround), this is because of the old and obsolete code that v4 was built (in the past, was a very nice code). In v5 we don't need to trigger the re-render manually, we have the watchers in useEffect as we are using React Hooks, you just should know what prop you need to update and trigger the re-rendering.

I think the problem may be related to that, because now you are using react hooks.
As I'm injecting the icons into the dom and not into virtual dom, maybe it doesn't detect the update of the coordinates. I say this because the variable information detects changes in the object but does not inject the x and y into your html (tooltip box).
For now I will stay with version 4. It's a very specific situation and since it' s for the work I can't share the video.
Is there any possibility of putting a ref on your box?  Maybe I could inject through the forwardRef.
Another situation, if it is an object and it is empty, in my case, it still shows the start box. I need to validate that the object.length to appear afterwards.

Another situation, if it is an object and it is empty, in my case, it still shows the box even with empty data. I need to validate that the object.length to appear afterwards.

v5.2.0 fixes this, the tooltip is not shown when content is empty.

Is there any possibility of putting a ref on your box? Maybe I could inject through the forwardRef.

This doesn't seem like it would help much.

For now I will stay with version 4.

For sure then. If you'd like to migrate to v5 in the future, try preparing a demo that you'd be allowed to share, or at least a video so we can understand exactly your use case.


Please separate your modules into different packages [feat]

Describe the problem
The dependencies for some of your modules interfere with other nodes that I use.  That being said I really love your animation nodes. Is there anyway that you could divide this up so that I can use the nodes that are good and not have the ones that won't load and break everyone else's nodes?

Alternatives considered
I have considered using loopchain instead but, the save paths and such are really weird, Your animation builder is great!
Additional context
No response

Yep, the idea is not to split but have true optional nodes as in they don't install their dependencies by default.
This will be the case for the most problematic ones: FaceSwap, FaceRestore and FILM (from the top of my head).
This will avoid a lot of the issues and now I clearly redirect to other nodes for the face stuff since it's not a main focus but was more an early experiment I kept iterating on.

closed by: https://github.com/melMass/comfy_mtb/commit/5dfea51dd8db2a4829e559eadeda22374b51c8a4


lxc cli: allow multiple filters

Unsure if this is a bug, since this "feature" isn't explicitly mentioned in the usage.
Required information

The output of "lxc info" or if that fails:

LXC version: branch master
LXD version: branch master

Issue description
When filtering for containers lxc list "filter...", you can't set multiple filters. According to the code currently on master:

while correctly assigning all remaining args to filters and beeing passed through
this function, while still looping through the filters, returns the result already when the first filter is processed
so ignoring further filters

Steps to reproduce

Step one

have a centos container without privileged
have a ubuntu container without privileged

Step two
lxc list "security.privileged=false" "image.os=ubuntu" should show only the ubuntu container, but is listing both
or lxc list "security.privileged=false" "image.os=nonexistent" should show none

I could do a PR for that, but I'm unsure if this fits your plans with args

Yeah, I think we want the filters to be applied as AND, not OR and we definitely should update the help to clarify the behavior. So a PR would be welcome.


Could you provide the dataset StreetViewText-Perspective(svtp) download links?

I want to make the svtp lmdb, but I found the original download url in original paper ' http://www.comp.nus.edu.sg/~phanquyt/' is not reachable, may you share it with me ? Thanks!

I have found these dataset at https://github.com/bgshih/aster/releases/, thanks anyway!


Fix Present1 params when scrolling the entire viewport

This commit makes a few changes to avoid bugs, but they basically boil
down to: When we scroll by an entire viewport worth of content, we must
ensure that the scroll offset is 0, because otherwise the scroll rect
(that's basically the viewport, but excluding the scroll offset) will
end up being empty, which the Present1 API chokes on. This commit
avoids this situation by shuffling around some code to first calculate
the dirty rows, then check if it affects all of them and in that case
sets the scroll offset to 0, and only then finally actually does any
scrolling if there's still something to scroll.
Validation Steps Performed

Start pwsh
Zoom in twice with Ctrl+Scrollwheel
Print a few viewports worth of text
Press Ctrl+L
No errors ✅

Hey, the feature flag build might fail because of the unpackaged build artifact. As long as it passes in compilation, feel free to merge when you have signoffs.


rename auth group to public. create private route group and add appropriate pages

Once we fix the conflicts here, LGTM


add Dockerfile

Great work here! I would love a Dockerfile to build this all.  I'll submit a PR if I get a chance to create one.

Thanks -- a PR would be great!


Format by stylua

CI is failing on the stylua --check, so I formatted it with stylua.
make integration still fails vusted, but it didn't seem like it would be fixed right away, so I would like to PR just the format first.

LGTM. Thank you.


stream_recv Read Exhaustion

getting my bearings with QUIC and Quiche.
say a message gets broken up into 5 packets.
when you read on the ready stream with stream_recv, I assume it is not aware of how many packets need to be read to fully exhaust the message it's working on, so just like a regular TCP socket you have to keep reading on stream_recv in a loop until you've read all your bytes?

Yes pretty much. Quiche handles all of the stream data reassembly from packets back into contiguous byte stream, this is done as you read data from a UDP socket and pass the QUIC packets into quiche. Streams become readable once data has arrived and remain so until it is read, see https://docs.quic.tech/quiche/struct.Connection.html#method.readable
// Iterate over readable streams.
for stream_id in conn.readable() {
    // Stream is readable, read until there's no more data.
    while let Ok((read, fin)) = conn.stream_recv(stream_id, &mut buf) {
        println!("Got {} bytes on stream {}", read, stream_id);
    }
}

haha whoops sorry i missed the...

"Stream is readable, read until there's no more data."

Is there a trivial way to handle the readiness yourself? Integrating quiche into an existing server library with it's own io_uring event loop.

I'm not sure I follow your question. For reading, we only know if there's stream data once we consume a packet (conn.recv()) and run all the frame processing. Readiness to read from the UDP socket can be done by whatever means you like though.

oh okay I mistakenly thought from that snippet you included that there was some kind of blocking and polling going on behind the scenes in conn.readable().
So after the connection has been established and the socket informs it has bytes to read, I call quiche_conn_recv instead of a regular recv, and that's how the bytes "get into quiche"?
And then after quiche_conn_recv i must also call quiche_conn_stream_recv?


Dependent compilation of tests, examples ... etc

Turn of build of optional yap parts (tests, examples, ...) see #99.

Ha!  I just asked for a PR for this in the ticket you opened, and here it is already ready.  LGTM.


useful features for animejs

I missed some functions from a dead library (mojs) created by LegoMushroom
Shape (https://github.com/mojs/mojs/blob/master/api/shape.md)
ShapeSwirl (https://github.com/mojs/mojs/blob/master/api/shape-swirl.md)
Burst (https://github.com/mojs/mojs/blob/master/api/burst.md)
What do you say about such functions in animejs?
I believe that such possibilities greatly help to create beautiful animations

Here is an approach for Burst with animejs
https://codepen.io/gaougalos/pen/eoxgjv?editors=0010

Love the idea, will look a the feasibility for the next major update.

@gaou-piou @juliangarnier
This would be amazing!!


Add support for AtlanticElectricalHeaterWithAdjustableTemperatureSetpoint (io:AtlanticElectricalHeaterWithAdjustableTemperatureSetpointIOComponent)

Device information
Sauter Ipala elelectrical heater (1000W and 1500W) not recognized as a Climate entity.
Would like to be able to set the target temperature and the operating mode (BASIC, PROG, VACATION, OFF).
Temperature, Contact and Occupancy sensors are discovered.
Device details
2020-10-25 10:23:48 DEBUG (MainThread) [custom_components.tahoma] Unsupported TaHoma device detected (io:AtlanticElectricalHeaterWithAdjustableTemperatureSetpointIOComponent - HeatingSystem - AtlanticElectricalHeaterWithAdjustableTemperatureSetpoint)
{
	"commands": [{
		"commandName": "cancelHeatingLevel",
		"nparams": 1
	}, {
		"commandName": "delayedStopIdentify",
		"nparams": 1
	}, {
		"commandName": "getName",
		"nparams": 0
	}, {
		"commandName": "identify",
		"nparams": 0
	}, {
		"commandName": "noPersonInside",
		"nparams": 0
	}, {
		"commandName": "off",
		"nparams": 0
	}, {
		"commandName": "personInside",
		"nparams": 0
	}, {
		"commandName": "refreshComfortTemperature",
		"nparams": 0
	}, {
		"commandName": "refreshDateTime",
		"nparams": 0
	}, {
		"commandName": "refreshDerogatedTargetTemperature",
		"nparams": 0
	}, {
		"commandName": "refreshEcoTemperature",
		"nparams": 0
	}, {
		"commandName": "refreshHeatingLevel",
		"nparams": 0
	}, {
		"commandName": "refreshIdentifier",
		"nparams": 0
	}, {
		"commandName": "refreshManufacturerName",
		"nparams": 0
	}, {
		"commandName": "refreshMaximumHeatingTargetTemperature",
		"nparams": 0
	}, {
		"commandName": "refreshMaximumTargetTemperature",
		"nparams": 0
	}, {
		"commandName": "refreshOperatingMode",
		"nparams": 0
	}, {
		"commandName": "refreshTargetTemperature",
		"nparams": 0
	}, {
		"commandName": "refreshTemperature",
		"nparams": 0
	}, {
		"commandName": "refreshTimeProgram",
		"nparams": 0
	}, {
		"commandName": "setComfortTemperature",
		"nparams": 1
	}, {
		"commandName": "setDateTime",
		"nparams": 1
	}, {
		"commandName": "setDerogatedTargetTemperature",
		"nparams": 1
	}, {
		"commandName": "setEcoTemperature",
		"nparams": 1
	}, {
		"commandName": "setHeatingLevel",
		"nparams": 1
	}, {
		"commandName": "setHeatingLevelWithTimer",
		"nparams": 2
	}, {
		"commandName": "setHolidays",
		"nparams": 1
	}, {
		"commandName": "setHolidaysTargetTemperature",
		"nparams": 1
	}, {
		"commandName": "setName",
		"nparams": 1
	}, {
		"commandName": "setOccupancyActivation",
		"nparams": 1
	}, {
		"commandName": "setOccupancy",
		"nparams": 1
	}, {
		"commandName": "setOpenWindowDetectionActivation",
		"nparams": 1
	}, {
		"commandName": "setOperatingMode",
		"nparams": 1
	}, {
		"commandName": "setPreviousTargetTemperature",
		"nparams": 1
	}, {
		"commandName": "setSchedulingType",
		"nparams": 1
	}, {
		"commandName": "setTargetTemperature",
		"nparams": 1
	}, {
		"commandName": "setTimeProgram",
		"nparams": 1
	}, {
		"commandName": "startIdentify",
		"nparams": 0
	}, {
		"commandName": "stopIdentify",
		"nparams": 0
	}, {
		"commandName": "wink",
		"nparams": 1
	}, {
		"commandName": "pairOneWayController",
		"nparams": 2
	}, {
		"commandName": "refreshAutoProgram",
		"nparams": 0
	}, {
		"commandName": "refreshControllerAddress",
		"nparams": 0
	}, {
		"commandName": "refreshCumulatedLowering",
		"nparams": 0
	}, {
		"commandName": "refreshCurrentWorkingRate",
		"nparams": 0
	}, {
		"commandName": "refreshDeletionCancelation",
		"nparams": 0
	}, {
		"commandName": "refreshEffectiveTemperatureSetpoint",
		"nparams": 0
	}, {
		"commandName": "refreshLocalLeadTime",
		"nparams": 0
	}, {
		"commandName": "refreshModel",
		"nparams": 0
	}, {
		"commandName": "refreshNativeFunctionalLevel",
		"nparams": 0
	}, {
		"commandName": "refreshPeakNotice",
		"nparams": 0
	}, {
		"commandName": "refreshPeakWarning",
		"nparams": 0
	}, {
		"commandName": "refreshPowerAndTension",
		"nparams": 0
	}, {
		"commandName": "refreshRoomDeletionThreshold",
		"nparams": 0
	}, {
		"commandName": "refreshSetpointLoweringTemperatureInProgMode",
		"nparams": 0
	}, {
		"commandName": "refreshSynchronisationRequest",
		"nparams": 0
	}, {
		"commandName": "refreshTemperatureProbeCalibrationOffset",
		"nparams": 0
	}, {
		"commandName": "setCommunicationTest",
		"nparams": 1
	}, {
		"commandName": "setDeletionCancelation",
		"nparams": 1
	}, {
		"commandName": "setExpectedPresence",
		"nparams": 1
	}, {
		"commandName": "setHeatingLevelForTrigger",
		"nparams": 1
	}, {
		"commandName": "setNativeLevelsList",
		"nparams": 1
	}, {
		"commandName": "setPeakNotice",
		"nparams": 1
	}, {
		"commandName": "setPeakWarning",
		"nparams": 1
	}, {
		"commandName": "setRoomDeletionThreshold",
		"nparams": 1
	}, {
		"commandName": "setSetpointLoweringTemperatureInProgMode",
		"nparams": 1
	}, {
		"commandName": "setTemperatureProbeCalibrationOffset",
		"nparams": 1
	}, {
		"commandName": "setTwinningExit",
		"nparams": 1
	}, {
		"commandName": "unpairAllOneWayControllers",
		"nparams": 0
	}, {
		"commandName": "unpairOneWayController",
		"nparams": 2
	}],
	"states": [{
		"type": "ContinuousState",
		"qualifiedName": "core:ComfortRoomTemperatureState"
	}, {
		"type": "DataState",
		"qualifiedName": "core:DateTimeState"
	}, {
		"type": "ContinuousState",
		"qualifiedName": "core:DerogatedTargetTemperatureState"
	}, {
		"values": ["good", "low", "normal", "verylow"],
		"type": "DiscreteState",
		"qualifiedName": "core:DiscreteRSSILevelState"
	}, {
		"type": "ContinuousState",
		"qualifiedName": "core:EcoRoomTemperatureState"
	}, {
		"values": ["off", "on"],
		"type": "DiscreteState",
		"qualifiedName": "core:HolidaysModeState"
	}, {
		"type": "ContinuousState",
		"qualifiedName": "core:HolidaysTargetTemperatureState"
	}, {
		"type": "DataState",
		"qualifiedName": "core:IdentifierState"
	}, {
		"type": "DataState",
		"qualifiedName": "core:ManufacturerNameState"
	}, {
		"type": "ContinuousState",
		"qualifiedName": "core:MaximumHeatingTargetTemperatureState"
	}, {
		"type": "ContinuousState",
		"qualifiedName": "core:MaximumTargetTemperatureState"
	}, {
		"type": "DataState",
		"qualifiedName": "core:NameState"
	}, {
		"values": ["active", "inactive"],
		"type": "DiscreteState",
		"qualifiedName": "core:OccupancyActivationState"
	}, {
		"values": ["off", "on"],
		"type": "DiscreteState",
		"qualifiedName": "core:OnOffState"
	}, {
		"values": ["active", "inactive"],
		"type": "DiscreteState",
		"qualifiedName": "core:OpenWindowDetectionActivationState"
	}, {
		"values": ["antifreeze", "auto", "away", "eco", "frostprotection", "manual", "max", "normal", "off", "on", "prog", "program"],
		"type": "DiscreteState",
		"qualifiedName": "core:OperatingModeState"
	}, {
		"type": "ContinuousState",
		"qualifiedName": "core:PreviousTargetTemperatureState"
	}, {
		"type": "ContinuousState",
		"qualifiedName": "core:PriorityLockTimerState"
	}, {
		"type": "ContinuousState",
		"qualifiedName": "core:RSSILevelState"
	}, {
		"values": ["increase", "none", "standby"],
		"type": "DiscreteState",
		"qualifiedName": "core:RegulationModeState"
	}, {
		"values": ["available", "unavailable"],
		"type": "DiscreteState",
		"qualifiedName": "core:StatusState"
	}, {
		"type": "ContinuousState",
		"qualifiedName": "core:TargetTemperatureState"
	}, {
		"type": "DataState",
		"qualifiedName": "core:TimeProgramState"
	}, {
		"type": "ContinuousState",
		"qualifiedName": "core:VersionState"
	}, {
		"type": "DataState",
		"qualifiedName": "io:AutoProgramState"
	}, {
		"type": "DataState",
		"qualifiedName": "io:ControllerAddressState"
	}, {
		"type": "ContinuousState",
		"qualifiedName": "io:CumulatedLoweringState"
	}, {
		"type": "ContinuousState",
		"qualifiedName": "io:CurrentWorkingRateState"
	}, {
		"values": ["deletion cancelation", "no deletion cancelation"],
		"type": "DiscreteState",
		"qualifiedName": "io:DeletionCancelationState"
	}, {
		"type": "ContinuousState",
		"qualifiedName": "io:EffectiveTemperatureSetpointState"
	}, {
		"type": "ContinuousState",
		"qualifiedName": "io:ExpectedPresenceState"
	}, {
		"values": ["external", "internal"],
		"type": "DiscreteState",
		"qualifiedName": "io:InternalExternalSchedulingTypeState"
	}, {
		"type": "ContinuousState",
		"qualifiedName": "io:LocalLeadTimeState"
	}, {
		"values": ["boost", "comfort", "comfort-1", "comfort-2", "eco", "frostprotection", "off", "secured"],
		"type": "DiscreteState",
		"qualifiedName": "io:MaximumHeatingLevelState"
	}, {
		"type": "DataState",
		"qualifiedName": "io:ModelState"
	}, {
		"values": ["base", "medium", "top"],
		"type": "DiscreteState",
		"qualifiedName": "io:NativeFunctionalLevelState"
	}, {
		"values": ["long peak", "no peak", "short peak"],
		"type": "DiscreteState",
		"qualifiedName": "io:PeakNoticeState"
	}, {
		"values": ["long peak warning", "no warning", "short peak warning"],
		"type": "DiscreteState",
		"qualifiedName": "io:PeakWarningState"
	}, {
		"type": "DataState",
		"qualifiedName": "io:PowerState"
	}, {
		"values": ["comfortLevel1", "comfortLevel2", "comfortLevel3", "comfortLevel4", "environmentProtection", "humanProtection", "userLevel1", "userLevel2"],
		"type": "DiscreteState",
		"qualifiedName": "io:PriorityLockLevelState"
	}, {
		"values": ["LSC", "SAAC", "SFC", "UPS", "externalGateway", "localUser", "myself", "rain", "security", "temperature", "timer", "user", "wind"],
		"type": "DiscreteState",
		"qualifiedName": "io:PriorityLockOriginatorState"
	}, {
		"type": "DataState",
		"qualifiedName": "io:RoomDeletionThresholdState"
	}, {
		"values": ["kept", "lost"],
		"type": "DiscreteState",
		"qualifiedName": "io:RunningState"
	}, {
		"type": "ContinuousState",
		"qualifiedName": "io:SetpointLoweringTemperatureInProgModeState"
	}, {
		"values": ["boost", "comfort", "comfort-1", "comfort-2", "eco", "frostprotection", "off", "secured"],
		"type": "DiscreteState",
		"qualifiedName": "io:TargetHeatingLevelState"
	}, {
		"type": "ContinuousState",
		"qualifiedName": "io:TemperatureProbeCalibrationOffsetState"
	}, {
		"type": "DataState",
		"qualifiedName": "io:TensionState"
	}, {
		"type": "ContinuousState",
		"qualifiedName": "io:TimerForTransitoryStateState"
	}, {
		"type": "ContinuousState",
		"qualifiedName": "io:UptimeState"
	}],
	"dataProperties": [{
		"value": "500",
		"qualifiedName": "core:identifyInterval"
	}],
	"widgetName": "AtlanticElectricalHeaterWithAdjustableTemperatureSetpoint",
	"uiClass": "HeatingSystem",
	"uiClassifiers": ["emitter"],
	"qualifiedName": "io:AtlanticElectricalHeaterWithAdjustableTemperatureSetpointIOComponent",
	"type": "ACTUATOR"
}

Related issues: https://github.com/iMicknl/ha-tahoma/issues/339

👍.

Hello, any plan for support ?
Thanks.

Hi @LoicRivoal! For sure, we would love to add support for this climate device as well. Currently we are a bit busy with the preparation for adding this integration to core.
I marked this issue as help wanted, which means that it won't be auto closed and that it can be discovered more easily.

@LoicRivoal, version 2.3.8 was just released with new info in debug log. Could you install it, activate debug log and report the device urls of the thermostat you want added, and the temperature sensor that goes with it?
In the same way as https://github.com/iMicknl/ha-tahoma/issues/322#issuecomment-751477333. It helps us to develop a climate device for this integration.

@LoicRivoal, version 2.3.8 was just released with new info in debug log. Could you install it, activate debug log and report the device urls of the thermostat you want added, and the temperature sensor that goes with it?
In the same way as https://github.com/iMicknl/ha-tahoma/issues/322#issuecomment-751477333. It helps us to develop a climate device for this integration.

Device information
Sauter Ipala elelectrical heater (1000W and 1500W) not recognized as a Climate entity.
Would like to be able to set the target temperature and the operating mode (BASIC, PROG, VACATION, OFF).
Temperature, Contact and Occupancy sensors are discovered.
Device details
2021-01-09 10:24:28 DEBUG (MainThread) [custom_components.tahoma.coordinator] Initialized DataUpdateCoordinator with 0:00:30 interval.
2021-01-09 10:24:28 DEBUG (MainThread) [custom_components.tahoma] Finished fetching TaHoma Event Fetcher data in 0.110 seconds
2021-01-09 10:24:28 INFO (MainThread) [custom_components.tahoma] HomeKit support detected with setup code 741-88-222.
2021-01-09 10:24:28 DEBUG (MainThread) [custom_components.tahoma] Added Device (internal:TSKAlarmComponent - Alarm - TSKAlarmController - internal://1233-1403-4125/alarm/0)
2021-01-09 10:24:28 DEBUG (MainThread) [custom_components.tahoma] Unsupported TaHoma device detected (io:AtlanticElectricalHeaterWithAdjustableTemperatureSetpointIOComponent - HeatingSystem - AtlanticElectricalHeaterWithAdjustableTemperatureSetpoint - io://1233-1403-4125/10261942#1)
2021-01-09 10:24:28 DEBUG (MainThread) [custom_components.tahoma] Added Device (io:TemperatureInCelciusIOSystemDeviceSensor - TemperatureSensor - TemperatureSensor - io://1233-1403-4125/10261942#2)
2021-01-09 10:24:28 DEBUG (MainThread) [custom_components.tahoma] Added Device (io:ContactIOSystemDeviceSensor - ContactSensor - ContactSensor - io://1233-1403-4125/10261942#3)
2021-01-09 10:24:28 DEBUG (MainThread) [custom_components.tahoma] Added Device (io:OccupancyIOSystemDeviceSensor - OccupancySensor - OccupancySensor - io://1233-1403-4125/10261942#4)
2021-01-09 10:24:28 DEBUG (MainThread) [custom_components.tahoma] Added Device (io:CumulatedElectricalEnergyConsumptionIOSystemDeviceSensor - ElectricitySensor - CumulativeElectricPowerConsumptionSensor - io://1233-1403-4125/10261942#5)
2021-01-09 10:24:28 DEBUG (MainThread) [custom_components.tahoma] Unsupported TaHoma device detected (io:AtlanticElectricalHeaterWithAdjustableTemperatureSetpointIOComponent - HeatingSystem - AtlanticElectricalHeaterWithAdjustableTemperatureSetpoint - io://1233-1403-4125/7176909#1)
2021-01-09 10:24:28 DEBUG (MainThread) [custom_components.tahoma] Added Device (io:TemperatureInCelciusIOSystemDeviceSensor - TemperatureSensor - TemperatureSensor - io://1233-1403-4125/7176909#2)
2021-01-09 10:24:28 DEBUG (MainThread) [custom_components.tahoma] Added Device (io:ContactIOSystemDeviceSensor - ContactSensor - ContactSensor - io://1233-1403-4125/7176909#3)
2021-01-09 10:24:28 DEBUG (MainThread) [custom_components.tahoma] Added Device (io:OccupancyIOSystemDeviceSensor - OccupancySensor - OccupancySensor - io://1233-1403-4125/7176909#4)
2021-01-09 10:24:28 DEBUG (MainThread) [custom_components.tahoma] Added Device (io:CumulatedElectricalEnergyConsumptionIOSystemDeviceSensor - ElectricitySensor - CumulativeElectricPowerConsumptionSensor - io://1233-1403-4125/7176909#5)
2021-01-09 10:24:28 DEBUG (MainThread) [custom_components.tahoma] Added Device (io:RollerShutterVeluxIOComponent - RollerShutter - PositionableTiltedRollerShutter - io://1233-1403-4125/7455234)
2021-01-09 10:24:28 DEBUG (MainThread) [custom_components.tahoma] Added Device (io:RollerShutterVeluxIOComponent - RollerShutter - PositionableTiltedRollerShutter - io://1233-1403-4125/8417774)
2021-01-09 10:24:28 DEBUG (MainThread) [custom_components.tahoma] Unsupported TaHoma device detected (rtds:RTDSRemoteControllerComponent - RemoteController - AlarmRemoteController - rtds://1233-1403-4125/170304)
2021-01-09 10:24:58 DEBUG (MainThread) [custom_components.tahoma] Finished fetching TaHoma Event Fetcher data in 0.058 seconds
2021-01-09 10:25:28 DEBUG (MainThread) [custom_components.tahoma] Finished fetching TaHoma Event Fetcher data in 0.053 seconds
2021-01-09 10:25:58 DEBUG (MainThread) [custom_components.tahoma] Finished fetching TaHoma Event Fetcher data in 0.060 seconds
2021-01-09 10:26:28 DEBUG (MainThread) [custom_components.tahoma] Finished fetching TaHoma Event Fetcher data in 0.049 seconds
2021-01-09 10:26:58 DEBUG (MainThread) [custom_components.tahoma] Finished fetching TaHoma Event Fetcher data in 0.047 seconds
2021-01-09 10:27:28 DEBUG (MainThread) [custom_components.tahoma] Finished fetching TaHoma Event Fetcher data in 0.051 seconds
2021-01-09 10:27:58 DEBUG (MainThread) [custom_components.tahoma] Finished fetching TaHoma Event Fetcher data in 0.048 seconds

Device information
Sauter Ipala elelectrical heater (1000W and 1500W) not recognized as a Climate entity.
Would like to be able to set the target temperature and the operating mode (BASIC, PROG, VACATION, OFF).
Temperature, Contact and Occupancy sensors are discovered.
Device details
2021-01-09 10:24:28 DEBUG (MainThread) [custom_components.tahoma.coordinator] Initialized DataUpdateCoordinator with 0:00:30 interval.
2021-01-09 10:24:28 DEBUG (MainThread) [custom_components.tahoma] Finished fetching TaHoma Event Fetcher data in 0.110 seconds
2021-01-09 10:24:28 INFO (MainThread) [custom_components.tahoma] HomeKit support detected with setup code 741-88-222.
2021-01-09 10:24:28 DEBUG (MainThread) [custom_components.tahoma] Added Device (internal:TSKAlarmComponent - Alarm - TSKAlarmController - internal://1233-1403-4125/alarm/0)
2021-01-09 10:24:28 DEBUG (MainThread) [custom_components.tahoma] Unsupported TaHoma device detected (io:AtlanticElectricalHeaterWithAdjustableTemperatureSetpointIOComponent - HeatingSystem - AtlanticElectricalHeaterWithAdjustableTemperatureSetpoint - io://1233-1403-4125/10261942#1)
2021-01-09 10:24:28 DEBUG (MainThread) [custom_components.tahoma] Added Device (io:TemperatureInCelciusIOSystemDeviceSensor - TemperatureSensor - TemperatureSensor - io://1233-1403-4125/10261942#2)
2021-01-09 10:24:28 DEBUG (MainThread) [custom_components.tahoma] Added Device (io:ContactIOSystemDeviceSensor - ContactSensor - ContactSensor - io://1233-1403-4125/10261942#3)
2021-01-09 10:24:28 DEBUG (MainThread) [custom_components.tahoma] Added Device (io:OccupancyIOSystemDeviceSensor - OccupancySensor - OccupancySensor - io://1233-1403-4125/10261942#4)
2021-01-09 10:24:28 DEBUG (MainThread) [custom_components.tahoma] Added Device (io:CumulatedElectricalEnergyConsumptionIOSystemDeviceSensor - ElectricitySensor - CumulativeElectricPowerConsumptionSensor - io://1233-1403-4125/10261942#5)
2021-01-09 10:24:28 DEBUG (MainThread) [custom_components.tahoma] Unsupported TaHoma device detected (io:AtlanticElectricalHeaterWithAdjustableTemperatureSetpointIOComponent - HeatingSystem - AtlanticElectricalHeaterWithAdjustableTemperatureSetpoint - io://1233-1403-4125/7176909#1)
2021-01-09 10:24:28 DEBUG (MainThread) [custom_components.tahoma] Added Device (io:TemperatureInCelciusIOSystemDeviceSensor - TemperatureSensor - TemperatureSensor - io://1233-1403-4125/7176909#2)
2021-01-09 10:24:28 DEBUG (MainThread) [custom_components.tahoma] Added Device (io:ContactIOSystemDeviceSensor - ContactSensor - ContactSensor - io://1233-1403-4125/7176909#3)
2021-01-09 10:24:28 DEBUG (MainThread) [custom_components.tahoma] Added Device (io:OccupancyIOSystemDeviceSensor - OccupancySensor - OccupancySensor - io://1233-1403-4125/7176909#4)
2021-01-09 10:24:28 DEBUG (MainThread) [custom_components.tahoma] Added Device (io:CumulatedElectricalEnergyConsumptionIOSystemDeviceSensor - ElectricitySensor - CumulativeElectricPowerConsumptionSensor - io://1233-1403-4125/7176909#5)
2021-01-09 10:24:28 DEBUG (MainThread) [custom_components.tahoma] Added Device (io:RollerShutterVeluxIOComponent - RollerShutter - PositionableTiltedRollerShutter - io://1233-1403-4125/7455234)
2021-01-09 10:24:28 DEBUG (MainThread) [custom_components.tahoma] Added Device (io:RollerShutterVeluxIOComponent - RollerShutter - PositionableTiltedRollerShutter - io://1233-1403-4125/8417774)
2021-01-09 10:24:28 DEBUG (MainThread) [custom_components.tahoma] Unsupported TaHoma device detected (rtds:RTDSRemoteControllerComponent - RemoteController - AlarmRemoteController - rtds://1233-1403-4125/170304)
2021-01-09 10:24:58 DEBUG (MainThread) [custom_components.tahoma] Finished fetching TaHoma Event Fetcher data in 0.058 seconds
2021-01-09 10:25:28 DEBUG (MainThread) [custom_components.tahoma] Finished fetching TaHoma Event Fetcher data in 0.053 seconds
2021-01-09 10:25:58 DEBUG (MainThread) [custom_components.tahoma] Finished fetching TaHoma Event Fetcher data in 0.060 seconds
2021-01-09 10:26:28 DEBUG (MainThread) [custom_components.tahoma] Finished fetching TaHoma Event Fetcher data in 0.049 seconds
2021-01-09 10:26:58 DEBUG (MainThread) [custom_components.tahoma] Finished fetching TaHoma Event Fetcher data in 0.047 seconds
2021-01-09 10:27:28 DEBUG (MainThread) [custom_components.tahoma] Finished fetching TaHoma Event Fetcher data in 0.051 seconds
2021-01-09 10:27:58 DEBUG (MainThread) [custom_components.tahoma] Finished fetching TaHoma Event Fetcher data in 0.048 seconds

2021-01-13 16:36:25 DEBUG (MainThread) [custom_components.tahoma.coordinator] Initialized DataUpdateCoordinator with 0:00:30 interval.
2021-01-13 16:36:25 DEBUG (MainThread) [custom_components.tahoma] Finished fetching TaHoma Event Fetcher data in 0.627 seconds
2021-01-13 16:36:25 DEBUG (MainThread) [custom_components.tahoma] Unsupported TaHoma device detected (io:AtlanticElectricalHeaterWithAdjustableTemperatureSetpointIOComponent - HeatingSystem - AtlanticElectricalHeaterWithAdjustableTemperatureSetpoint - io://0805-4652-8486/15748583#1)
2021-01-13 16:36:25 DEBUG (MainThread) [custom_components.tahoma] Added TaHoma device (io:TemperatureInCelciusIOSystemDeviceSensor - TemperatureSensor - TemperatureSensor - io://0805-4652-8486/15748583#2)
2021-01-13 16:36:25 DEBUG (MainThread) [custom_components.tahoma] Added TaHoma device (io:ContactIOSystemDeviceSensor - ContactSensor - ContactSensor - io://0805-4652-8486/15748583#3)
2021-01-13 16:36:25 DEBUG (MainThread) [custom_components.tahoma] Added TaHoma device (io:OccupancyIOSystemDeviceSensor - OccupancySensor - OccupancySensor - io://0805-4652-8486/15748583#4)
2021-01-13 16:36:25 DEBUG (MainThread) [custom_components.tahoma] Added TaHoma device (io:CumulatedElectricalEnergyConsumptionIOSystemDeviceSensor - ElectricitySensor - CumulativeElectricPowerConsumptionSensor - io://0805-4652-8486/15748583#5)
2021-01-13 16:36:25 DEBUG (MainThread) [custom_components.tahoma] Unsupported TaHoma device detected (io:AtlanticElectricalHeaterWithAdjustableTemperatureSetpointIOComponent - HeatingSystem - AtlanticElectricalHeaterWithAdjustableTemperatureSetpoint - io://0805-4652-8486/446684#1)
2021-01-13 16:36:25 DEBUG (MainThread) [custom_components.tahoma] Added TaHoma device (io:TemperatureInCelciusIOSystemDeviceSensor - TemperatureSensor - TemperatureSensor - io://0805-4652-8486/446684#2)
2021-01-13 16:36:25 DEBUG (MainThread) [custom_components.tahoma] Added TaHoma device (io:ContactIOSystemDeviceSensor - ContactSensor - ContactSensor - io://0805-4652-8486/446684#3)
2021-01-13 16:36:25 DEBUG (MainThread) [custom_components.tahoma] Added TaHoma device (io:OccupancyIOSystemDeviceSensor - OccupancySensor - OccupancySensor - io://0805-4652-8486/446684#4)
2021-01-13 16:36:25 DEBUG (MainThread) [custom_components.tahoma] Added TaHoma device (io:CumulatedElectricalEnergyConsumptionIOSystemDeviceSensor - ElectricitySensor - CumulativeElectricPowerConsumptionSensor - io://0805-4652-8486/446684#5)
2021-01-13 16:36:25 DEBUG (MainThread) [custom_components.tahoma] Added TaHoma device (io:AtlanticElectricalHeaterIOComponent - HeatingSystem - AtlanticElectricalHeater - io://0805-4652-8486/9390644)
2021-01-13 16:36:56 DEBUG (MainThread) [custom_components.tahoma] Finished fetching TaHoma Event Fetcher data in 0.293 seconds

2021-01-13 16:36:25 DEBUG (MainThread) [custom_components.tahoma.coordinator] Initialized DataUpdateCoordinator with 0:00:30 interval.
2021-01-13 16:36:25 DEBUG (MainThread) [custom_components.tahoma] Finished fetching TaHoma Event Fetcher data in 0.627 seconds
2021-01-13 16:36:25 DEBUG (MainThread) [custom_components.tahoma] Unsupported TaHoma device detected (io:AtlanticElectricalHeaterWithAdjustableTemperatureSetpointIOComponent - HeatingSystem - AtlanticElectricalHeaterWithAdjustableTemperatureSetpoint - io://0805-4652-8486/15748583#1)
2021-01-13 16:36:25 DEBUG (MainThread) [custom_components.tahoma] Added TaHoma device (io:TemperatureInCelciusIOSystemDeviceSensor - TemperatureSensor - TemperatureSensor - io://0805-4652-8486/15748583#2)
2021-01-13 16:36:25 DEBUG (MainThread) [custom_components.tahoma] Added TaHoma device (io:ContactIOSystemDeviceSensor - ContactSensor - ContactSensor - io://0805-4652-8486/15748583#3)
2021-01-13 16:36:25 DEBUG (MainThread) [custom_components.tahoma] Added TaHoma device (io:OccupancyIOSystemDeviceSensor - OccupancySensor - OccupancySensor - io://0805-4652-8486/15748583#4)
2021-01-13 16:36:25 DEBUG (MainThread) [custom_components.tahoma] Added TaHoma device (io:CumulatedElectricalEnergyConsumptionIOSystemDeviceSensor - ElectricitySensor - CumulativeElectricPowerConsumptionSensor - io://0805-4652-8486/15748583#5)
2021-01-13 16:36:25 DEBUG (MainThread) [custom_components.tahoma] Unsupported TaHoma device detected (io:AtlanticElectricalHeaterWithAdjustableTemperatureSetpointIOComponent - HeatingSystem - AtlanticElectricalHeaterWithAdjustableTemperatureSetpoint - io://0805-4652-8486/446684#1)
2021-01-13 16:36:25 DEBUG (MainThread) [custom_components.tahoma] Added TaHoma device (io:TemperatureInCelciusIOSystemDeviceSensor - TemperatureSensor - TemperatureSensor - io://0805-4652-8486/446684#2)
2021-01-13 16:36:25 DEBUG (MainThread) [custom_components.tahoma] Added TaHoma device (io:ContactIOSystemDeviceSensor - ContactSensor - ContactSensor - io://0805-4652-8486/446684#3)
2021-01-13 16:36:25 DEBUG (MainThread) [custom_components.tahoma] Added TaHoma device (io:OccupancyIOSystemDeviceSensor - OccupancySensor - OccupancySensor - io://0805-4652-8486/446684#4)
2021-01-13 16:36:25 DEBUG (MainThread) [custom_components.tahoma] Added TaHoma device (io:CumulatedElectricalEnergyConsumptionIOSystemDeviceSensor - ElectricitySensor - CumulativeElectricPowerConsumptionSensor - io://0805-4652-8486/446684#5)
2021-01-13 16:36:25 DEBUG (MainThread) [custom_components.tahoma] Added TaHoma device (io:AtlanticElectricalHeaterIOComponent - HeatingSystem - AtlanticElectricalHeater - io://0805-4652-8486/9390644)
2021-01-13 16:36:56 DEBUG (MainThread) [custom_components.tahoma] Finished fetching TaHoma Event Fetcher data in 0.293 seconds

Hi,
Is there any support for a climate entity supposed to have been introduced in 2.4.x?
Thanks.

Hi,
Is there any support for a climate entity supposed to have been introduced in 2.4.x?
Thanks.

@LoicRivoal no, support hasn't been introduced yet. I will see if I can come up with a basic test version soon, would be great if you could give that one a try and report back.

@LoicRivoal no, support hasn't been introduced yet. I will see if I can come up with a basic test version soon, would be great if you could give that one a try and report back.

Yes for sure I will be able to do that.

Yes for sure I will be able to do that.

I'm here to test too .mu might have a look on the cozytouch integration as well ?

I'm here to test too .mu might have a look on the cozytouch integration as well ?

I'm here to test too .mu might have a look on the cozytouch integration as well ?

Will do, in the end I would love to port some great work of hass-cozytouch to this integration.
@thundergreen, I tried to contact the original author of hass-cozytouch, but I haven't been able to establish contact yet. (see https://github.com/Cyr-ius/hass-cozytouch/issues/30). There are quite some issus on that GitHub repo which should already be solved / supported in ha-tahoma.

I'm here to test too .mu might have a look on the cozytouch integration as well ?

Will do, in the end I would love to port some great work of hass-cozytouch to this integration.
@thundergreen, I tried to contact the original author of hass-cozytouch, but I haven't been able to establish contact yet. (see https://github.com/Cyr-ius/hass-cozytouch/issues/30). There are quite some issus on that GitHub repo which should already be solved / supported in ha-tahoma.

Could you try the following version? https://github.com/iMicknl/ha-tahoma/archive/enhancement/AtlanticElectricalHeaterWithAdjustableTemperatureSetpoint.zip
Please extract the custom_components/tahoma folder and place this within your current custom_components folder.

Could you try the following version? https://github.com/iMicknl/ha-tahoma/archive/enhancement/AtlanticElectricalHeaterWithAdjustableTemperatureSetpoint.zip
Please extract the custom_components/tahoma folder and place this within your current custom_components folder.

@iMicknl You meant me? I will test  and report :) Thanks !

@iMicknl You meant me? I will test  and report :) Thanks !

@iMicknl You meant me? I will test and report :) Thanks !

Anyone with this device can test :-)

@iMicknl You meant me? I will test and report :) Thanks !

Anyone with this device can test :-)

I'll test an report with peasure :)

I'll test an report with peasure :)

both heater appeared.. will test if they work also :) Thanks so far seems a very good beginning :)

both heater appeared.. will test if they work also :) Thanks so far seems a very good beginning :)

both heater appeared.. will test if they work also :) Thanks so far seems a very good beginning :)

Great to hear. The current temperature is not implemented yet by the way, so that is not working.
If you did use another CozyTouch integration, it would be great what did work there and not in the current TaHoma implementation.

both heater appeared.. will test if they work also :) Thanks so far seems a very good beginning :)

Great to hear. The current temperature is not implemented yet by the way, so that is not working.
If you did use another CozyTouch integration, it would be great what did work there and not in the current TaHoma implementation.

Both climate entities appear as well for me.  Temperature setpoint works.
On/Off does not seem to work. I am not quite sure how the preset modes should operate ( boost
comfort 1,  comfort 2,  comfort, eco,   Frost Protection,  none).
The only modes I have on the heater display screen is BASIC and PROG.
in the Tahoma app I have PROG, HOLIDAYS, BASIC, OFF.
Today I am using an Homebridge Tahoma plugin that sets the mode to AUTO, which is displayed on the heater screen as an additional mode with an empty line ....and displayed on the Tahoma app as HOLIDAYS with an additional "A" on the icon of the heater ...The AUTO mode is suuposed to be for heaters with an occupancy sensor, an occupancy sensor is reported for those Ipala heaters but they are not supposed to have one ...
Thanks for your time !

Both climate entities appear as well for me.  Temperature setpoint works.
On/Off does not seem to work. I am not quite sure how the preset modes should operate ( boost
comfort 1,  comfort 2,  comfort, eco,   Frost Protection,  none).
The only modes I have on the heater display screen is BASIC and PROG.
in the Tahoma app I have PROG, HOLIDAYS, BASIC, OFF.
Today I am using an Homebridge Tahoma plugin that sets the mode to AUTO, which is displayed on the heater screen as an additional mode with an empty line ....and displayed on the Tahoma app as HOLIDAYS with an additional "A" on the icon of the heater ...The AUTO mode is suuposed to be for heaters with an occupancy sensor, an occupancy sensor is reported for those Ipala heaters but they are not supposed to have one ...
Thanks for your time !

{
	"values": ["antifreeze", "auto", "away", "eco", "frostprotection", "manual", "max", "normal", "off", "on", "prog", "program"],
	"type": "DiscreteState",
	"qualifiedName": "core:OperatingModeState"
}

I will see if I can implement those OperatingMode... Currently these are mapped to HVAC modes. Let's see how the current CozyTouch implementation is doing this.
I just pushed a new version that implements the on command. Could you turn on debug mode and share your log as well?

{
	"values": ["antifreeze", "auto", "away", "eco", "frostprotection", "manual", "max", "normal", "off", "on", "prog", "program"],
	"type": "DiscreteState",
	"qualifiedName": "core:OperatingModeState"
}

I will see if I can implement those OperatingMode... Currently these are mapped to HVAC modes. Let's see how the current CozyTouch implementation is doing this.
I just pushed a new version that implements the on command. Could you turn on debug mode and share your log as well?

Could it be possible that you need to have the heater set to PROG mode on its screen so that Tahoma can control it?  Like on the pilot white controller (bottom phrase)?

Could it be possible that you need to have the heater set to PROG mode on its screen so that Tahoma can control it?  Like on the pilot white controller (bottom phrase)?

On the tahomalink interface, you can use the Chrome developer panel to find out what commands are sent for each mode. I have a clip ready to show how to do that if needed.

On the tahomalink interface, you can use the Chrome developer panel to find out what commands are sent for each mode. I have a clip ready to show how to do that if needed.

Hello. Well I tried your initial support for cozytouch but it seems controlling just doesn't work at all :( I'll send you logfiles later if you are OK :)

Hello. Well I tried your initial support for cozytouch but it seems controlling just doesn't work at all :( I'll send you logfiles later if you are OK :)

{
	"values": ["antifreeze", "auto", "away", "eco", "frostprotection", "manual", "max", "normal", "off", "on", "prog", "program"],
	"type": "DiscreteState",
	"qualifiedName": "core:OperatingModeState"
}

I will see if I can implement those OperatingMode... Currently these are mapped to HVAC modes. Let's see how the current CozyTouch implementation is doing this.
I just pushed a new version that implements the on command. Could you turn on debug mode and share your log as well?

Can you please share the link to download the latest dev version ech time? :) Or do i just use dev via hacs ?

{
	"values": ["antifreeze", "auto", "away", "eco", "frostprotection", "manual", "max", "normal", "off", "on", "prog", "program"],
	"type": "DiscreteState",
	"qualifiedName": "core:OperatingModeState"
}

I will see if I can implement those OperatingMode... Currently these are mapped to HVAC modes. Let's see how the current CozyTouch implementation is doing this.
I just pushed a new version that implements the on command. Could you turn on debug mode and share your log as well?

Can you please share the link to download the latest dev version ech time? :) Or do i just use dev via hacs ?

When in development, it is not possible to download the latest version via HACS. We are using in a different branch, which can be downloaded here: https://github.com/iMicknl/ha-tahoma/archive/enhancement/AtlanticElectricalHeaterWithAdjustableTemperatureSetpoint.zip.
If you look at this list, you can see if there have been any updates to the code: https://github.com/iMicknl/ha-tahoma/commits/enhancement/AtlanticElectricalHeaterWithAdjustableTemperatureSetpoint.

When in development, it is not possible to download the latest version via HACS. We are using in a different branch, which can be downloaded here: https://github.com/iMicknl/ha-tahoma/archive/enhancement/AtlanticElectricalHeaterWithAdjustableTemperatureSetpoint.zip.
If you look at this list, you can see if there have been any updates to the code: https://github.com/iMicknl/ha-tahoma/commits/enhancement/AtlanticElectricalHeaterWithAdjustableTemperatureSetpoint.

works pretty well.
I am not quite sure the Tahoma app or portal is the best way to follow as they don't even show the current temperature for some strange marketing reason. This is how it works :
PROG --> follows programmed schedules, schedules cannot be programmed in the app/portal, only at the appliance. Window and Occupancy sensors can be activated/deactivated --> HVAC : auto, PRESET MODE : comfort, PROG displayed at the heater
BASIC --> does not take into account window  and occupancy sensors to regulate temp, does not follow any programmed schedule --> HVAC : heating, PRESET MODE : comfort, BASIC displayed at the heater
HOLIDAYS -->  HVAC : heating, PRESET MODE : Frost protection, H.Gel displayed at the heater
OFF --> turn off
on the climate entity card, the schedule icon puts the heater in PROG mode, the flame icon puts the heater in BASIC mode, ON/OFF icon does not work. Curent temperature seems to work.
Now it looks like the Sauter (or Thermor or ...) android app is more complete, I can only play with its demo mode as I don't have a Cozytouch box but a Tahoma one.
Current temperature is indicated, heating status as well.  Schedules can be programmed in the application with the choice of PRESET mode for the time range (confort, eco). There is a global AWAY mode that sets heaters to Frost Protection.
According to models heaters can be set to OFF, BASIC, PROG and additionnally AUTO for the models with an occupancy sensor.
Coming back to what I mentionned before, my Ipala heaters are not supposed to have an occupancy sensor according to their documentation, there is no such capability in the menus (as opposed to window open sensor)  BUT the Tahoma app and all integrations reports its presence and the Homebridge Tahoma plugin can set the heater mode to AUTO (A additional letter appears in Tahoma app), conclusion for that ?

I am not quite sure the Tahoma app or portal is the best way to follow as they don't even show the current temperature for some strange marketing reason. This is how it works :
PROG --> follows programmed schedules, schedules cannot be programmed in the app/portal, only at the appliance. Window and Occupancy sensors can be activated/deactivated --> HVAC : auto, PRESET MODE : comfort, PROG displayed at the heater
BASIC --> does not take into account window  and occupancy sensors to regulate temp, does not follow any programmed schedule --> HVAC : heating, PRESET MODE : comfort, BASIC displayed at the heater
HOLIDAYS -->  HVAC : heating, PRESET MODE : Frost protection, H.Gel displayed at the heater
OFF --> turn off
on the climate entity card, the schedule icon puts the heater in PROG mode, the flame icon puts the heater in BASIC mode, ON/OFF icon does not work. Curent temperature seems to work.
Now it looks like the Sauter (or Thermor or ...) android app is more complete, I can only play with its demo mode as I don't have a Cozytouch box but a Tahoma one.
Current temperature is indicated, heating status as well.  Schedules can be programmed in the application with the choice of PRESET mode for the time range (confort, eco). There is a global AWAY mode that sets heaters to Frost Protection.
According to models heaters can be set to OFF, BASIC, PROG and additionnally AUTO for the models with an occupancy sensor.
Coming back to what I mentionned before, my Ipala heaters are not supposed to have an occupancy sensor according to their documentation, there is no such capability in the menus (as opposed to window open sensor)  BUT the Tahoma app and all integrations reports its presence and the Homebridge Tahoma plugin can set the heater mode to AUTO (A additional letter appears in Tahoma app), conclusion for that ?

Another way that would help us a lot is to do all requests via the official apps and to capture them. We are working on a feature (https://github.com/iMicknl/ha-tahoma/archive/feature/add_history_service.zip) where you can easily retrieve the execution history + parameters in Home Assistant logging.
In order to gather more information, you can use the tahoma.get_execution_history service which will print your execution history to the Home Assistant log. Run the commands via the official vendor (e.g. TaHoma) app and capture the commands.
Installing the version above will mean that you temporarily the Atlantic heater support, however we will soon merge everything together.

Thanks @LoicRivoal!
Another way that would help us a lot is to do all requests via the official apps and to capture them. We are working on a feature (https://github.com/iMicknl/ha-tahoma/archive/feature/add_history_service.zip) where you can easily retrieve the execution history + parameters in Home Assistant logging.
In order to gather more information, you can use the tahoma.get_execution_history service which will print your execution history to the Home Assistant log. Run the commands via the official vendor (e.g. TaHoma) app and capture the commands.
Installing the version above will mean that you temporarily the Atlantic heater support, however we will soon merge everything together.

OFF --> BASIC 19°
BASIC 19° --> OFF
OFF --> PROG 19°/WINDOW+OCCUPANCY sensors ON
PROG 19°/WINDOW+OCCUPANCY sensors ON --> PROG 20°/WINDOW+OCCUPANCY sensors ON
PROG 20°/WINDOW+OCCUPANCY sensors ON --> HOLIDAYS/AWAY until 31/01
HOLIDAYS/AWAY until 31/01 --> BASIC 19°
OFF --> BASIC 19°
2021-01-29 09:10:51 INFO (MainThread) [custom_components.tahoma] 2021-01-28 19:28:43: setTargetTemperature executed via Combles 1500W - Basique - 19.0 °C - AndroidPhone on io://1233-1403-4125/7176909#1, with [19.0].
2021-01-29 09:10:51 INFO (MainThread) [custom_components.tahoma] 2021-01-28 19:28:43: setOperatingMode executed via Combles 1500W - Basique - 19.0 °C - AndroidPhone on io://1233-1403-4125/7176909#1, with ['basic'].
2021-01-29 09:10:51 INFO (MainThread) [custom_components.tahoma] 2021-01-28 19:28:35: setTargetTemperature executed via Combles 1000W - Basique - 19.0 °C - AndroidPhone on io://1233-1403-4125/10261942#1, with [19.0].
2021-01-29 09:10:51 INFO (MainThread) [custom_components.tahoma] 2021-01-28 19:28:35: setOperatingMode executed via Combles 1000W - Basique - 19.0 °C - AndroidPhone on io://1233-1403-4125/10261942#1, with ['basic'].
BASIC 19° --> OFF
2021-01-29 09:10:51 INFO (MainThread) [custom_components.tahoma] 2021-01-28 19:31:10: setOperatingMode executed via Combles 1500W - Off - AndroidPhone on io://1233-1403-4125/7176909#1, with ['standby'].
2021-01-29 09:10:51 INFO (MainThread) [custom_components.tahoma] 2021-01-28 19:31:04: setOperatingMode executed via Combles 1000W - Off - AndroidPhone on io://1233-1403-4125/10261942#1, with ['standby'].
OFF --> PROG 19°/WINDOW+OCCUPANCY sensors ON
2021-01-29 09:10:51 INFO (MainThread) [custom_components.tahoma] 2021-01-28 19:33:24: setOperatingMode executed via Combles 1500W - Prog - fenêtre - absence - AndroidPhone on io://1233-1403-4125/7176909#1, with ['internal'].
2021-01-29 09:10:51 INFO (MainThread) [custom_components.tahoma] 2021-01-28 19:33:08: setOperatingMode executed via Combles 1000W - Prog - fenêtre - absence - AndroidPhone on io://1233-1403-4125/10261942#1, with ['internal'].
PROG 19°/WINDOW+OCCUPANCY sensors ON --> PROG 20°/WINDOW+OCCUPANCY sensors ON
2021-01-29 09:10:51 INFO (MainThread) [custom_components.tahoma] 2021-01-28 19:38:16: setOperatingMode executed via Combles 1500W - Prog - fenêtre - absence - AndroidPhone on io://1233-1403-4125/7176909#1, with ['internal'].
2021-01-29 09:10:51 INFO (MainThread) [custom_components.tahoma] 2021-01-28 19:38:16: setDerogatedTargetTemperature executed via Combles 1500W - Prog - fenêtre - absence - AndroidPhone on io://1233-1403-4125/7176909#1, with [19.0].
2021-01-29 09:10:51 INFO (MainThread) [custom_components.tahoma] 2021-01-28 19:38:08: setOperatingMode executed via Combles 1000W - Prog - fenêtre - absence - AndroidPhone on io://1233-1403-4125/10261942#1, with ['internal'].
2021-01-29 09:10:51 INFO (MainThread) [custom_components.tahoma] 2021-01-28 19:38:08: setDerogatedTargetTemperature executed via Combles 1000W - Prog - fenêtre - absence - AndroidPhone on io://1233-1403-4125/10261942#1, with [20.0].
PROG 20°/WINDOW+OCCUPANCY sensors ON --> HOLIDAYS/AWAY until 31/01
2021-01-29 09:10:51 INFO (MainThread) [custom_components.tahoma] 2021-01-28 19:40:08: setHeatingLevel executed via Combles 1500W - Mode vacances - Jusqu'au 31/012021 - AndroidPhone on io://1233-1403-4125/7176909#1, with ['frostprotection'].
2021-01-29 09:10:51 INFO (MainThread) [custom_components.tahoma] 2021-01-28 19:39:57: setHeatingLevel executed via Combles 1000W - Mode vacances - Jusqu'au 31/012021 - AndroidPhone on io://1233-1403-4125/10261942#1, with ['frostprotection'].
HOLIDAYS/AWAY until 31/01 --> BASIC 19°
2021-01-29 09:10:51 INFO (MainThread) [custom_components.tahoma] 2021-01-28 19:42:11: setTargetTemperature executed via Combles 1500W - Basique - 19.0 °C - AndroidPhone on io://1233-1403-4125/7176909#1, with [19.0].
2021-01-29 09:10:51 INFO (MainThread) [custom_components.tahoma] 2021-01-28 19:42:11: setOperatingMode executed via Combles 1500W - Basique - 19.0 °C - AndroidPhone on io://1233-1403-4125/7176909#1, with ['basic'].
2021-01-29 09:10:51 INFO (MainThread) [custom_components.tahoma] 2021-01-28 19:42:11: cancelHeatingLevel executed via Combles 1500W - Basique - 19.0 °C - AndroidPhone on io://1233-1403-4125/7176909#1, with ['frostprotection'].
2021-01-29 09:10:51 INFO (MainThread) [custom_components.tahoma] 2021-01-28 19:42:05: setTargetTemperature executed via Combles 1000W - Basique - 19.0 °C - AndroidPhone on io://1233-1403-4125/10261942#1, with [19.0].
2021-01-29 09:10:51 INFO (MainThread) [custom_components.tahoma] 2021-01-28 19:42:05: setOperatingMode executed via Combles 1000W - Basique - 19.0 °C - AndroidPhone on io://1233-1403-4125/10261942#1, with ['basic'].
2021-01-29 09:10:51 INFO (MainThread) [custom_components.tahoma] 2021-01-28 19:42:05: cancelHeatingLevel executed via Combles 1000W - Basique - 19.0 °C - AndroidPhone on io://1233-1403-4125/10261942#1, with ['frostprotection'].

ok, it was actually in the log for that sessions, is that what you need ?
OFF --> BASIC 19°
BASIC 19° --> OFF
OFF --> PROG 19°/WINDOW+OCCUPANCY sensors ON
PROG 19°/WINDOW+OCCUPANCY sensors ON --> PROG 20°/WINDOW+OCCUPANCY sensors ON
PROG 20°/WINDOW+OCCUPANCY sensors ON --> HOLIDAYS/AWAY until 31/01
HOLIDAYS/AWAY until 31/01 --> BASIC 19°
OFF --> BASIC 19°
2021-01-29 09:10:51 INFO (MainThread) [custom_components.tahoma] 2021-01-28 19:28:43: setTargetTemperature executed via Combles 1500W - Basique - 19.0 °C - AndroidPhone on io://1233-1403-4125/7176909#1, with [19.0].
2021-01-29 09:10:51 INFO (MainThread) [custom_components.tahoma] 2021-01-28 19:28:43: setOperatingMode executed via Combles 1500W - Basique - 19.0 °C - AndroidPhone on io://1233-1403-4125/7176909#1, with ['basic'].
2021-01-29 09:10:51 INFO (MainThread) [custom_components.tahoma] 2021-01-28 19:28:35: setTargetTemperature executed via Combles 1000W - Basique - 19.0 °C - AndroidPhone on io://1233-1403-4125/10261942#1, with [19.0].
2021-01-29 09:10:51 INFO (MainThread) [custom_components.tahoma] 2021-01-28 19:28:35: setOperatingMode executed via Combles 1000W - Basique - 19.0 °C - AndroidPhone on io://1233-1403-4125/10261942#1, with ['basic'].
BASIC 19° --> OFF
2021-01-29 09:10:51 INFO (MainThread) [custom_components.tahoma] 2021-01-28 19:31:10: setOperatingMode executed via Combles 1500W - Off - AndroidPhone on io://1233-1403-4125/7176909#1, with ['standby'].
2021-01-29 09:10:51 INFO (MainThread) [custom_components.tahoma] 2021-01-28 19:31:04: setOperatingMode executed via Combles 1000W - Off - AndroidPhone on io://1233-1403-4125/10261942#1, with ['standby'].
OFF --> PROG 19°/WINDOW+OCCUPANCY sensors ON
2021-01-29 09:10:51 INFO (MainThread) [custom_components.tahoma] 2021-01-28 19:33:24: setOperatingMode executed via Combles 1500W - Prog - fenêtre - absence - AndroidPhone on io://1233-1403-4125/7176909#1, with ['internal'].
2021-01-29 09:10:51 INFO (MainThread) [custom_components.tahoma] 2021-01-28 19:33:08: setOperatingMode executed via Combles 1000W - Prog - fenêtre - absence - AndroidPhone on io://1233-1403-4125/10261942#1, with ['internal'].
PROG 19°/WINDOW+OCCUPANCY sensors ON --> PROG 20°/WINDOW+OCCUPANCY sensors ON
2021-01-29 09:10:51 INFO (MainThread) [custom_components.tahoma] 2021-01-28 19:38:16: setOperatingMode executed via Combles 1500W - Prog - fenêtre - absence - AndroidPhone on io://1233-1403-4125/7176909#1, with ['internal'].
2021-01-29 09:10:51 INFO (MainThread) [custom_components.tahoma] 2021-01-28 19:38:16: setDerogatedTargetTemperature executed via Combles 1500W - Prog - fenêtre - absence - AndroidPhone on io://1233-1403-4125/7176909#1, with [19.0].
2021-01-29 09:10:51 INFO (MainThread) [custom_components.tahoma] 2021-01-28 19:38:08: setOperatingMode executed via Combles 1000W - Prog - fenêtre - absence - AndroidPhone on io://1233-1403-4125/10261942#1, with ['internal'].
2021-01-29 09:10:51 INFO (MainThread) [custom_components.tahoma] 2021-01-28 19:38:08: setDerogatedTargetTemperature executed via Combles 1000W - Prog - fenêtre - absence - AndroidPhone on io://1233-1403-4125/10261942#1, with [20.0].
PROG 20°/WINDOW+OCCUPANCY sensors ON --> HOLIDAYS/AWAY until 31/01
2021-01-29 09:10:51 INFO (MainThread) [custom_components.tahoma] 2021-01-28 19:40:08: setHeatingLevel executed via Combles 1500W - Mode vacances - Jusqu'au 31/012021 - AndroidPhone on io://1233-1403-4125/7176909#1, with ['frostprotection'].
2021-01-29 09:10:51 INFO (MainThread) [custom_components.tahoma] 2021-01-28 19:39:57: setHeatingLevel executed via Combles 1000W - Mode vacances - Jusqu'au 31/012021 - AndroidPhone on io://1233-1403-4125/10261942#1, with ['frostprotection'].
HOLIDAYS/AWAY until 31/01 --> BASIC 19°
2021-01-29 09:10:51 INFO (MainThread) [custom_components.tahoma] 2021-01-28 19:42:11: setTargetTemperature executed via Combles 1500W - Basique - 19.0 °C - AndroidPhone on io://1233-1403-4125/7176909#1, with [19.0].
2021-01-29 09:10:51 INFO (MainThread) [custom_components.tahoma] 2021-01-28 19:42:11: setOperatingMode executed via Combles 1500W - Basique - 19.0 °C - AndroidPhone on io://1233-1403-4125/7176909#1, with ['basic'].
2021-01-29 09:10:51 INFO (MainThread) [custom_components.tahoma] 2021-01-28 19:42:11: cancelHeatingLevel executed via Combles 1500W - Basique - 19.0 °C - AndroidPhone on io://1233-1403-4125/7176909#1, with ['frostprotection'].
2021-01-29 09:10:51 INFO (MainThread) [custom_components.tahoma] 2021-01-28 19:42:05: setTargetTemperature executed via Combles 1000W - Basique - 19.0 °C - AndroidPhone on io://1233-1403-4125/10261942#1, with [19.0].
2021-01-29 09:10:51 INFO (MainThread) [custom_components.tahoma] 2021-01-28 19:42:05: setOperatingMode executed via Combles 1000W - Basique - 19.0 °C - AndroidPhone on io://1233-1403-4125/10261942#1, with ['basic'].
2021-01-29 09:10:51 INFO (MainThread) [custom_components.tahoma] 2021-01-28 19:42:05: cancelHeatingLevel executed via Combles 1000W - Basique - 19.0 °C - AndroidPhone on io://1233-1403-4125/10261942#1, with ['frostprotection'].

I have a Cozytouch hub with several Thermor Emotion 3 heaters (with windows/occupancy sensor).
I installed the specific build linked in this issue and my heaters are now recognized, but several functions doesn't work.
I just succeed to set the Operation to "heat" and modify the temperature in this mode.
With this heaters, I have 4 modes : OFF, BASIC, PROG, AUTO (AUTO is a schedule generated by the heater according to the occupancy sensor detection).
For the commands, I have the same one as @LoicRivoal , I just have one more command for the 'AUTO' mode.
2021-02-04 13:45:34 INFO (MainThread) [custom_components.tahoma] 2021-02-02 17:06:21: setOperatingMode via Android 2.4.8#220 Set device mode : AUTO on io://0802-6014-6923/16597726#1, with ['auto'].

Here is my Cozytouch interface :

@iMicknl Hello, I finally installed the lastest development version and did a quick test... Great progress !    I was able to turn on the radiators (from off to Auto mode and change mode to Confort but I was not able to swith them off or move them out of frost protection...)... I will continue the tests later this week and let you know.  In the mean time, if you need something from me, let me know.  Thank you for your hard work !!!

Thanks @browetd. I haven't had time lately to work on this, so nothing changed after @LoicRivoal's testing. However there is a lot of information in this issue which is helpful for a further implementation.

Hi !
Here are the logs for the radiators in paired mode (3 "Thermor Equateur 4" radiators in the same room) with the different commands.
Equipment
io_15417413 : Thermor Equateur 4 vertical 2000W
io_385209 : Thermor Equateur 4 horizontal 2000W
io_9372945 : Thermor Equateur 4 horizontal 1000W
Orders with code
PROG -> OFF
2021-04-19 12:24:03 INFO (MainThread) [custom_components.tahoma] 2021-04-19 12:10:04: setOperatingMode executed via Android 2.5.1#236 Set device mode : OFF on io://0832-5072-2181/15417413#1, with ['standby']. 2021-04-19 12:24:03 INFO (MainThread) [custom_components.tahoma] 2021-04-19 12:10:04: setOperatingMode executed via Android 2.5.1#236 Set device mode : OFF on io://0832-5072-2181/385209#1, with ['standby']. 2021-04-19 12:24:03 INFO (MainThread) [custom_components.tahoma] 2021-04-19 12:10:04: setOperatingMode executed via Android 2.5.1#236 Set device mode : OFF on io://0832-5072-2181/9372945#1, with ['standby'].
OFF -> BASIC
2021-04-19 12:24:03 INFO (MainThread) [custom_components.tahoma] 2021-04-19 12:11:07: setOperatingMode executed via Android 2.5.1#236 Set device mode : BASIC on io://0832-5072-2181/15417413#1, with ['basic']. 2021-04-19 12:24:03 INFO (MainThread) [custom_components.tahoma] 2021-04-19 12:11:07: setOperatingMode executed via Android 2.5.1#236 Set device mode : BASIC on io://0832-5072-2181/385209#1, with ['basic']. 2021-04-19 12:24:03 INFO (MainThread) [custom_components.tahoma] 2021-04-19 12:11:07: setOperatingMode executed via Android 2.5.1#236 Set device mode : BASIC on io://0832-5072-2181/9372945#1, with ['basic'].
BASIC -> OFF
2021-04-19 12:24:03 INFO (MainThread) [custom_components.tahoma] 2021-04-19 12:12:05: setOperatingMode executed via Android 2.5.1#236 Set device mode : OFF on io://0832-5072-2181/15417413#1, with ['standby']. 2021-04-19 12:24:03 INFO (MainThread) [custom_components.tahoma] 2021-04-19 12:12:05: setOperatingMode executed via Android 2.5.1#236 Set device mode : OFF on io://0832-5072-2181/385209#1, with ['standby']. 2021-04-19 12:24:03 INFO (MainThread) [custom_components.tahoma] 2021-04-19 12:12:05: setOperatingMode executed via Android 2.5.1#236 Set device mode : OFF on io://0832-5072-2181/9372945#1, with ['standby'].
OFF -> AUTO
2021-04-19 12:24:03 INFO (MainThread) [custom_components.tahoma] 2021-04-19 12:13:05: setOperatingMode executed via Android 2.5.1#236 Set device mode : AUTO on io://0832-5072-2181/15417413#1, with ['auto']. 2021-04-19 12:24:03 INFO (MainThread) [custom_components.tahoma] 2021-04-19 12:13:05: setOperatingMode executed via Android 2.5.1#236 Set device mode : AUTO on io://0832-5072-2181/385209#1, with ['auto']. 2021-04-19 12:24:03 INFO (MainThread) [custom_components.tahoma] 2021-04-19 12:13:05: setOperatingMode executed via Android 2.5.1#236 Set device mode : AUTO on io://0832-5072-2181/9372945#1, with ['auto'].

OFF -> PROG (windows and occupancy sensor on)
2021-04-19 12:24:03 INFO (MainThread) [custom_components.tahoma] 2021-04-19 12:15:10: setOperatingMode executed via Android 2.5.1#236 Set device mode : PROG on io://0832-5072-2181/15417413#1, with ['internal']. 2021-04-19 12:24:03 INFO (MainThread) [custom_components.tahoma] 2021-04-19 12:15:10: refreshHeatingLevel executed via Android 2.5.1#236 Set device mode : PROG on io://0832-5072-2181/15417413#1, with []. 2021-04-19 12:24:03 INFO (MainThread) [custom_components.tahoma] 2021-04-19 12:15:10: setOperatingMode executed via Android 2.5.1#236 Set device mode : PROG on io://0832-5072-2181/385209#1, with ['internal']. 2021-04-19 12:24:03 INFO (MainThread) [custom_components.tahoma] 2021-04-19 12:15:10: refreshHeatingLevel executed via Android 2.5.1#236 Set device mode : PROG on io://0832-5072-2181/385209#1, with []. 2021-04-19 12:24:03 INFO (MainThread) [custom_components.tahoma] 2021-04-19 12:15:10: setOperatingMode executed via Android 2.5.1#236 Set device mode : PROG on io://0832-5072-2181/9372945#1, with ['internal']. 2021-04-19 12:24:03 INFO (MainThread) [custom_components.tahoma] 2021-04-19 12:15:10: refreshHeatingLevel executed via Android 2.5.1#236 Set device mode : PROG on io://0832-5072-2181/9372945#1, with [].
PROG (windows and occupancy sensor on) -> PROG (windows sensor off and occupancy sensor on)
2021-04-19 12:24:03 INFO (MainThread) [custom_components.tahoma] 2021-04-19 12:16:11: setOpenWindowDetectionActivation executed via Android 2.5.1#236 I2G Set window detection false on io://0832-5072-2181/15417413#1, with ['inactive']. 2021-04-19 12:24:03 INFO (MainThread) [custom_components.tahoma] 2021-04-19 12:16:11: setOpenWindowDetectionActivation executed via Android 2.5.1#236 I2G Set window detection false on io://0832-5072-2181/385209#1, with ['inactive']. 2021-04-19 12:24:03 INFO (MainThread) [custom_components.tahoma] 2021-04-19 12:16:11: setOpenWindowDetectionActivation executed via Android 2.5.1#236 I2G Set window detection false on io://0832-5072-2181/9372945#1, with ['inactive'].
PROG (windows sensor off and occupancy sensor on) -> PROG (windows and occupancy sensor on)
2021-04-19 12:24:03 INFO (MainThread) [custom_components.tahoma] 2021-04-19 12:17:05: setOpenWindowDetectionActivation executed via Android 2.5.1#236 I2G Set window detection true on io://0832-5072-2181/15417413#1, with ['active']. 2021-04-19 12:24:03 INFO (MainThread) [custom_components.tahoma] 2021-04-19 12:17:05: setOpenWindowDetectionActivation executed via Android 2.5.1#236 I2G Set window detection true on io://0832-5072-2181/385209#1, with ['active']. 2021-04-19 12:24:03 INFO (MainThread) [custom_components.tahoma] 2021-04-19 12:17:05: setOpenWindowDetectionActivation executed via Android 2.5.1#236 I2G Set window detection true on io://0832-5072-2181/9372945#1, with ['active'].
PROG (windows and occupancy sensor on) -> (windows sensor on and occupancy sensor off)
2021-04-19 12:24:03 INFO (MainThread) [custom_components.tahoma] 2021-04-19 12:18:07: setOccupancyActivation executed via Android 2.5.1#236 I2G Set Occupancy false on io://0832-5072-2181/15417413#1, with ['inactive']. 2021-04-19 12:24:03 INFO (MainThread) [custom_components.tahoma] 2021-04-19 12:18:07: setOccupancyActivation executed via Android 2.5.1#236 I2G Set Occupancy false on io://0832-5072-2181/385209#1, with ['inactive']. 2021-04-19 12:24:03 INFO (MainThread) [custom_components.tahoma] 2021-04-19 12:18:07: setOccupancyActivation executed via Android 2.5.1#236 I2G Set Occupancy false on io://0832-5072-2181/9372945#1, with ['inactive'].
PROG (windows sensor on and occupancy sensor off) -> PROG (windows and occupancy sensor on)
2021-04-19 12:24:03 INFO (MainThread) [custom_components.tahoma] 2021-04-19 12:19:08: setOccupancyActivation executed via Android 2.5.1#236 I2G Set Occupancy true on io://0832-5072-2181/15417413#1, with ['active']. 2021-04-19 12:24:03 INFO (MainThread) [custom_components.tahoma] 2021-04-19 12:19:08: setOccupancyActivation executed via Android 2.5.1#236 I2G Set Occupancy true on io://0832-5072-2181/385209#1, with ['active']. 2021-04-19 12:24:03 INFO (MainThread) [custom_components.tahoma] 2021-04-19 12:19:08: setOccupancyActivation executed via Android 2.5.1#236 I2G Set Occupancy true on io://0832-5072-2181/9372945#1, with ['active'].
PROG (20,5° confort) -> PROG (21° confort)
2021-04-19 12:24:03 INFO (MainThread) [custom_components.tahoma] 2021-04-19 12:20:13: setTargetTemperature executed via Android 2.5.1#236 I2G Set temperature on io://0832-5072-2181/15417413#1, with [21.0]. 2021-04-19 12:24:03 INFO (MainThread) [custom_components.tahoma] 2021-04-19 12:20:13: setTargetTemperature executed via Android 2.5.1#236 I2G Set temperature on io://0832-5072-2181/385209#1, with [21.0]. 2021-04-19 12:24:03 INFO (MainThread) [custom_components.tahoma] 2021-04-19 12:20:13: setTargetTemperature executed via Android 2.5.1#236 I2G Set temperature on io://0832-5072-2181/9372945#1, with [21.0].
PROG (21° confort) -> PROG (20,5° confort)
2021-04-19 12:24:03 INFO (MainThread) [custom_components.tahoma] 2021-04-19 12:21:10: setTargetTemperature executed via Android 2.5.1#236 I2G Set temperature on io://0832-5072-2181/15417413#1, with [20.5]. 2021-04-19 12:24:03 INFO (MainThread) [custom_components.tahoma] 2021-04-19 12:21:10: setTargetTemperature executed via Android 2.5.1#236 I2G Set temperature on io://0832-5072-2181/385209#1, with [20.5]. 2021-04-19 12:24:03 INFO (MainThread) [custom_components.tahoma] 2021-04-19 12:21:10: setTargetTemperature executed via Android 2.5.1#236 I2G Set temperature on io://0832-5072-2181/9372945#1, with [20.5].
Screenshot of my Cozytouch app

I will add after the code to modify the programming (temperature and comfort time)

Hello everybody,
Just bringing my own experience of ha-tahoma component with my SAUTER devices.
I also own 2 IPALA heater devices, as @LoicRivoal i think. I have the cozytouch bridge to control them, that i use with the official cozytouch app.
I also used ENKI domotic system (from Leroy Merlin), but i'm moving little by little to Home Assistant.
Before finding this issue, i tested Cyr-ius component : my two devices were found, and i used the thermostat-card to try to use them. However, i had a lot of problems and couldn't fully control them:

huge delay in the heater status update (from the heater to Home assistant) : when clicking on one button from the card, i could see the heater changing of mode, but the app was showing "Warning" lines in the log, and will eventually update few minutes after.
Impossibility to put the "PROG" mode, as the thermostat card only enables AUTO, BASIC & ON/OFF modes.
I tried to do it "manually" by calling the corresponding service in the "Development tools" panel, but it wouldn't work

By reading a lot of posts on different sites, i discovered the "https://dev.duboc.pro/tahoma/login" site and understood that my deviced were "AtlanticElectricalHeaterWithAdjustableTemperatureSetpoint".
That is how i reached this post, and discovered this component & the improvement for this type of device.
I tested it and.....it's perfect !
I had a lot of devices showing when adding the integration, with 11devices & 17 entities for 2 heaters + 1 cozytouch bridge !
The thermostat-card i use to control them respond immediately, with the update of status and so on.
Just few things that could be great to have (or maybe it is already present, but i couldn't find them):

hvac status (off, heating)?
the possibility to change the eco temperature & the confort temperature (as on the cozytouch app) : the temperature in the thermostat-card is only the confort temperature i guess, and i couldn't find in the different attributes of the entity, the value of the eco temperature.
the possibility to program them? i tried to use the scheduler-card (https://github.com/nielsfaber/scheduler-card), to have a ECO / CONFORT timetables, but it wouln't change the heater status (it only changes when i program a BASIC mode instead of prog).
Maybe we cannot overried cozytouch programmation?

Otherwise, thanks a lot for this improvement, i was quite disappointed not to be able to control my two heaters with Home Assistant, but this improvement is really perfect !
I hope the next official release will take into account those modifications.
If you need any additional test, i can give it a try (but i'm quite newbie in home assistant, so it could take some time !)
@+


exclude demo, benchmarks and profile from coverage

In the course of #507 @milessabin proposed that we exclude demo, benchmarks and profile from coverage for straightforward reasons.
@armanbilge proposed a mechanism of doing so, which is the path followed in the current PR which addresses the same. This uses the coverageEnabled flag in sbt project settings.
Quick question, should Unidocs also be excluded?

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (7c78389) 67.10% compared to head (eb3321a) 72.31%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #508      +/-   ##
==========================================
+ Coverage   67.10%   72.31%   +5.20%
==========================================
  Files          40       33       -7
  Lines        4682     4345     -337
  Branches      951      927      -24
==========================================
  Hits         3142     3142
+ Misses       1540     1203     -337

see 7 files with indirect coverage changes

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

I went ahead and excluded docs and unidocs from the coverage.


Crash when packaged in UE 4.27

Added the plugin to an empty UE 4.27 project with the Demo map from the plugin.
The packaged application crashes.

Changing the plugin type from "Developer" to "Runtime" fixed it.

I had the same issue in 5.3. The above solution solved it.
Thanks


Add overall Swarm architecture diagrams

File: engine/swarm/swarm-tutorial/index.md
Better have some architecture pictures to describe the whole picture of swarm.

@sarahpark do y'all have any swarm architectural diagrams pre-baked?

@nishanttotla Ping on this for ideas.

@johndmulhausen we used to have architecture diagrams that have been used in presentations before. Particularly one demonstrating cluster topology with 3 managers and 5 workers, and indicating that the managers replicate data using Raft while workers share information p2p using Gossip protocol. Is this the kind of thing you're looking for?

@mstanleyjones 🤔 not that I know of

Closing. Out of date and we don't have anyone to make the diagram.


Add Hugging Face TGI to ModelProvider UI

Add the 🤗Text Generation Inference Model Provider to the User Interface
For the short description I've used the tagline of its repo, for the longer one, your own documentation

seems like this was removed one purpose :/
#688

@simon376 it was, sorry. If there's a really strong case for this I'm open to hearing it, but the need to keep the UI simple is very top-of-mind for us, especially since the number of providers is growing. The basic heuristic on this is that providers that are made for multiple people and take a while to setup probably won't make the page. Aim of the UI is mostly to make things accessible for beginners

@simon376 it was, sorry. If there's a really strong case for this I'm open to hearing it, but the need to keep the UI simple is very top-of-mind for us, especially since the number of providers is growing. The basic heuristic on this is that providers that are made for multiple people and take a while to setup probably won't make the page. Aim of the UI is mostly to make things accessible for beginners

I see, that makes sense 👍


SAbDabTargetProvider column issue, update ChEMBL version

The SAbDab CSV has one column heading that changes to include the month and year. This required manual updates periodically. Currently in the tests it just logs that the column is missing.
New logic will search the list of column headings to find the first one that starts with Highest_Clin_Trial. If none is found, it uses Highest_Clin_Trial which will fail but at least be shown in the error message.
Since I was making changes anyway, I updated the baseVersion of ChEMBL to the latest (31), because the current behavior is to keep trying versions until it finds one, which leads to a bunch of ftp errors. (This may be a candidate for future development trying to figure out the version from the README or something.)

Nice catch and fix, @aliciaaevans! I just tested out the code and it checked out OK on my end. Also looks good in the Azure tests.


Attribute to store datamapper output on Integration

Or maybe it should be part of the Step perhaps, like a attribute to reference n files maybe?
@chirino @jimmidyson FYI

So this is what the data mapper produces -> https://github.com/redhat-ipaas/datamapper-ui/blob/master/src/app/lib/ipaas-data-mapper/models/mapping.definition.model.ts

Ah, is it then in just in configuredProperties as atlasMapping then?  I could go along with that...

The atlassmapping property currently stored in the Twitter to Salesforce Example integration is kinda totally different from that typescript interface :-/

@gashcrumb I think it needs to go in the altlasmapping field on the data mapper.
@mattrpav @chirino maybe you can shine a light on this? We are currently using the JSON mentioned in:
https://github.com/redhat-ipaas/ipaas-datamapper/issues/7

@gashcrumb the data mapper service on staging has been updated to contain the twitter and Salesforce classes, and I've updated the atlas mapping in the deployment.json for the data mapper to reflect the use of these classes. So it should be good to go now!


build apk --release crash. Execution failed for task ':app:minifyReleaseWithProguard'

cant build/run app and flutter doctor shows everything is ok:
flutter doctor -v
[✓] Flutter (Channel stable, v1.12.13+hotfix.8, on Linux, locale en_US.UTF-8)
• Flutter version 1.12.13+hotfix.8 at /home/USER/Android/flutter
• Framework revision 0b8abb4724 (6 weeks ago), 2020-02-11 11:44:36 -0800
• Engine revision e1e6ced81d
• Dart version 2.7.0
[✓] Android toolchain - develop for Android devices (Android SDK version 29.0.3)
• Android SDK at /home/USER/Android/Sdk
• Android NDK location not configured (optional; useful for native profiling
support)
• Platform android-29, build-tools 29.0.3
• Java binary at: /opt/android-studio/jre/bin/java
• Java version OpenJDK Runtime Environment (build
1.8.0_212-release-1586-b4-5784211)
• All Android licenses accepted.
[✓] Android Studio (version 3.6)
• Android Studio at /opt/android-studio
• Flutter plugin version 44.0.2
• Dart plugin version 192.7761
• Java version OpenJDK Runtime Environment (build
1.8.0_212-release-1586-b4-5784211)

Hi @r4v3r23
is it your case https://github.com/flutter/flutter/issues/53341?

@vlady

Hi @r4v3r23
is it your case #53341?

i changed to master channel and now im getting errors building apk --release, but --debug builds ok

@r4v3r23
Could you please share your flutter build apk --release --verbose log?

@r4v3r23
Could you please share your flutter build apk --release --verbose log?

its huge, heres just the red:
[        ] Warning: there were 460 unresolved references to classes or
interfaces.
[        ]          You may need to add missing library jars or update their
versions.
[        ]          If your code works fine without the missing classes, you can
suppress
[        ]          the warnings with '-dontwarn' options.
[        ]
(http://proguard.sourceforge.net/manual/troubleshooting.html#unresolvedclass)
[        ] Warning: there were 14 unresolved references to program class
members.
[        ]          Your input classes appear to be inconsistent.
[        ]          You may need to recompile the code.
[        ]
(http://proguard.sourceforge.net/manual/troubleshooting.html#unresolvedprogramcl
assmember)
[        ] Warning: there were 4 unresolved references to library class members.
[        ]          You probably need to update the library versions.
[        ]
(http://proguard.sourceforge.net/manual/troubleshooting.html#unresolvedlibrarycl
assmember)
[  +62 ms] FAILURE: Build failed with an exception.
[        ] * What went wrong:
[        ] Execution failed for task ':app:minifyReleaseWithProguard'.
[        ] > java.io.IOException: Please correct the above warnings first.
[        ] * Try:
[        ] Run with --stacktrace option to get the stack trace. Run with --info
or --debug option to get more log output. Run with --scan to get full insights.
[        ] * Get more help at https://help.gradle.org
[        ] BUILD FAILED in 28s
[        ] 44 actionable tasks: 6 executed, 38 up-to-date
[ +342 ms] Running Gradle task 'assembleRelease'... (completed in 28.9s)
[   +4 ms] "flutter apk" took 29,153ms.
Gradle task assembleRelease failed with exit code 1
#0      throwToolExit (package:flutter_tools/src/base/common.dart:14:3)
#1      buildGradleApp (package:flutter_tools/src/android/gradle.dart:452:7)
#2      _rootRunUnary (dart:async/zone.dart:1155:38)
#3      _CustomZone.runUnary (dart:async/zone.dart:1048:19)
#4      _FutureListener.handleValue (dart:async/future_impl.dart:141:18)
#5      Future._propagateToListeners.handleValueCallback
(dart:async/future_impl.dart:682:45)
#6      Future._propagateToListeners (dart:async/future_impl.dart:711:32)
#7      Future._completeWithValue (dart:async/future_impl.dart:526:5)
#8      Future._asyncComplete.
(dart:async/future_impl.dart:556:7)
#9      _rootRun (dart:async/zone.dart:1147:13)
#10     _CustomZone.run (dart:async/zone.dart:1040:19)
#11     _CustomZone.runGuarded (dart:async/zone.dart:942:7)
#12     _CustomZone.bindCallbackGuarded.
(dart:async/zone.dart:982:23)
#13     _microtaskLoop (dart:async/schedule_microtask.dart:43:21)
#14     _startMicrotaskLoop (dart:async/schedule_microtask.dart:52:5)
#15     _runPendingImmediateCallback
(dart:isolate-patch/isolate_patch.dart:118:13)
#16     _RawReceivePortImpl._handleMessage
(dart:isolate-patch/isolate_patch.dart:169:5)

What went wrong:
Execution failed for task ':app:minifyReleaseWithProguard'.

java.io.IOException: Please correct the above warnings first.

I have the same error please help

I have the same error too. I clearly don't have anything with Proguard in my project.
Flutter version: 2.5.1

Hey guys, we solved this problem by setting the this in gradle.properties
android.enableR8=true

And set the flag --no-shrink when building the app bundle (as we don't what code shrinker). It works for us. I guess this is because if we set enableR8 to false Flutter will use Proguard by default.
I hope this will help someone in their stress of solving this like us.

God only this work for me. Thanks

Hey guys, we solved this problem by setting the this in gradle.properties
android.enableR8=true

And set the flag --no-shrink when building the app bundle (as we don't what code shrinker). It works for us. I guess this is because if we set enableR8 to false Flutter will use Proguard by default.
I hope this will help someone in their stress of solving this like us.