标签：＃<标签：0x00007FC4096DC868>
# 156

再次发布新的版本。我正在为将来的更改准备代码(比如支持向后计数仪表等)。所以这次发布主要是关于代码改进而不是功能改进。但仍然有一些。: slight_smile:请参阅下面的更改。

@mitchmario感谢您在卡可以看起来像什么设计。非常鼓舞人心。

0.0.8

新功能

  • 所有零值都被抑制。箭头上的值只有在相关时才可见。例如，在一个阳光明媚的日子，你生产的太阳能电池板的一部分被送回电网，另一部分被你的家庭消耗。
  • 与传感器相关的箭头的更多信息对话框。

改进

  • 当您单击单元以在视图之间切换时，立即响应。
  • 使用lite -element的本地版本。
  • 代码的改进。

修复

  • 更多信息对话框仅用于与传感器相关的图标。
  • 用于切换视图的缩小的可单击区域。
1像
# 157

嘿,Gerben,

文档版本更新至08。现在所有的观点都被数字所困扰，这些数字都是错误的，他们自己也是错误的。

50.

57.

03

这是正确的情况:

01

也。加载您的卡片再次测试它，使我的HA实例变得无响应，并导致自动重启。这张卡里有东西在困扰HA。开发状态和开发模板需要花费大量时间，如果它们出现的话……

04

我会再把它拿出来，等待下一个版本，希望你能解决问题。

# 158

嗨@Mariusthvdb，我可以试着解释这些值发生了什么，但我犹豫不决，因为上次我指向你的模板传感器方向时，你给了我“请不要走那条路线”。笑脸:笑脸:(你有一个模板传感器，它给出一个带有双负号的字符串结果。)

但我不是在讽刺你。让我们解释一下这些值是怎么回事:卡片不能很好地处理输入传感器，这些传感器给出了在不同时间测量的值。

Lovelace__Power_wheel_card_-Share_your_Projects____Lovelace___Frontend -_Home_Assistant_Community
在上面的示例（我拍摄了图像），太阳能输入传感器给出了0，并网格能量产生传感器给出0.18千瓦时。这是一个无效的组合，它本身就不会发生在现实生活中，但可以在哈哈中发生。因为传感器在不同时间通过HA测量。我自己很幸运有输入传感器，每10秒更新两秒钟。但是，如果太阳能传感器正在更新每分钟（例如，例如），并且电网传感器每30秒更新一次，则可以进入此问题。

Maybe the card should check these temporarily invalid input combinations, but I could check only for detectable invalid situations and the undetectable invalid (but still invalid) combinations still wouldn’t be detected because they are obscured by the data itself (= you can’t write a if-statement for it).

由于您也经历了性能问题，因此可以通过性能问题放大时序效果。

关于性能问题。虽然我有116个组件在HA中运行，没有性能问题，但这当然帮不了你。但另一方面，我的意思是，你有一个非常特殊的情况，我不能复制。也许动力轮卡的其他用户可以确认(或否认)0.0.8版本中与该卡相关的任何性能问题?

我想到的一件事是，如果您在HA的/dev-state en /dev-template页面上有问题，那么这与HA的后端有关。卡完全运行在前端，驻留在您的浏览器中，而不是在后端。

需要明确的是:如果关闭卡，您不会遇到任何性能问题吗?在浏览器的控制台中是否看到任何错误或警告?应该没有。

# 159

不确定。我的大多数传感器都是实时更新的，我的netto_verbruik传感器及其模板，我认为每10秒更新一次，是DSMR更新这些。

这是另一个视图，所有显示都很好，我可以看到每个传感器更新和响应其他:

46

他们都展示了我的设置，常规和可爱的罚款。这是当您的卡被使用时，性能严重妨碍。而且，在每个新版本中，出现新的问题，必须调整模板或传感器，以便您的卡使用数据的方式调整。这根本就是我害怕......

我是一个沉重的用户，录取，使用128个组件。但他们都很好。大多数情况下，只有色调有一些问题，但显然只是我的信使继续前进。正如我可以使用您的卡所看到的，Hue Light展示不可用......（其他故事）它确实发出负担系统的信号。

但事情改变了，现在这表明:

14
19
24

这会更好地反映你的设计吗?

_更新
对中心切换的响应是即时的，所以这确实要好得多。

是的，每次我测试你的卡都是这样。这在更新到最新版本后也会立即产生效果。不过，我很好奇你刚才说的话，我想可能和历史有关。自从我开始使用HA以来，它一直表现得很糟糕，对许多人来说也是如此。所以我检查了其他使用它的东西，找到了history-graph，当然还有mini-graph-card-bundle seeLovelace:迷你显卡。我暂时禁用了它，看看会发生什么。(我一起使用你的卡和迷你卡片)

它似乎有效果…不确定它是否全部消失，但如果我使用任一纸牌，事情加速。如果我两者都使用，我得到的结果是:自动重启，系统停止，当尝试加载检查器时，我的浏览器杀死自己并重新加载页面，然后它不会这样做……你知道问题的具体情况)
需要进一步检查。

尽管如此，前端所发生的一切都是有代价的，特别是需要进行大量定制。不确定这是让你释怀还是悲伤的原因。

# 160

感谢您的广泛回复。是的，现在的图像确实反映了当前的设计。今晚我花了几个小时研究性能改进的可能性。发现了一些微量元素肩膀（）有帮助的功能。

发生了什么？HA给每个定制卡大哈斯财产。卡片检查这个哈斯对象，用于更改实体。默认情况下，HA和lite元素卡是为更新而设计的每一个可见张每一个的变化每一个实体(=自动化、传感器、脚本等)。对于具有许多实体的大型HA设置，如果您将其与一种或多种较重的卡片组合在一起，这可能会成为一个问题。：酡：

我对动力轮卡做了改动，只在特定实体发生变化时更新卡片(例如，所有输入传感器)。这样可以跳过大量不必要的更新，并释放一些浏览器资源。有一个0.0.9-dev版本dev分支如果你想试试的话。

但是由于HA更新了可见在Lovelace中，你也可以尝试将每一种较重的卡片暂时隔离在一个单独的视图中进行测试。这种方法可以帮助查明特定卡片的性能问题。

我希望开发-发布和测试方法最终能够解决你的一些性能问题，如果不是全部的话。: slight_smile:

Lovelace:迷你显卡
# 161

现在测试……

35

请允许2个建议:

太阳图标下缺失的0对我来说有点太干净了......事实上，它给出了传感器没有拾取的不确定感觉。如果没有太阳能生产可以在图标下显示0，我更喜欢它。

其次，如果卡片的标题随着视图和显示而改变，Power- Watt, Usage/Energy - kwh and Cost(这听起来比Money iyam更好)，而不是Power Distribution或我们给它的任何固定标题，它现在显示出来了。

谢谢你试图让它更好，如果有任何东西，那么没有报道，好或坏......

更新

在取出迷你图卡让它运行一天以上，我可以报告大部分性能问题已经消失。显然，这两张卡的组合会带来麻烦。不知道如何和问什么可以检查的原因，但请让我标签@Kalkih.这里看看？FYI，我正在使用HA 084.3。

# 162

我已经考虑了你的两个建议。而且我讨论了迷你图卡主题的表现，非常兴趣。

# 163

酷。虽然我已经不再使用我的卡了，但这对系统来说太沉重了。你的动力轮似乎在系统上更容易，所以这也很好眨眼:

# 164

我喜欢这张卡片的创意: slight_smile:

我有一个问题-我有一个Enphase系统使用一个特使- s，它提供网格消耗和阵列生产数据-有人使用这个卡与特使，如果是这样，你如何计算网格输出?

# 165

嗨@DrewXT，我看到你已经在另一个话题中得到了支持@Exxamalte.。超级!我知道卡片参数的命名可能会令人困惑。我将在下一个版本中添加更多的解释。(我想把参数名本身的更改推迟一段时间，因为这会导致中断的更改，而且人们还在从上次中断的更改中恢复。眨眼:)。

# 166

你好,

测试新卡，添加的选项似乎如承诺的那样工作眨眼:
尝试使用着色选项，我有点困惑，虽然如果我想要的是已经可能。

首先:我是否正确的图标不沿着自定义设置的个人实体在HA设置?

如果以上是真的，我怎么能

当> 0（生产）或灰色时，有太阳图标变为黄色;
当返回网格时，网格图标将变为绿色，并在消耗时红色
当仅使用太阳能时，home图标变为绿色，使用混合能源时变为橙色，仅使用电网能源时变为红色……

最后，我认为最好让房子的网格图标在消费时变成红色(而不是黄色的太阳能颜色箭头，当生产时是黄色的)

现在我们有2个选项，他们去找我认为的所有图标，这可能会更加富有洞察力。

如果尚未使用，请考虑此功能请求眨眼:

54.
02
12

# 167

电源轮卡新释放的时间。

0.0.9

特征

  • 通过使用可选的卡片参数为每个视图设置不同的标题title_power,title_energy和/或title_money。
    所有三个卡参数默认为卡参数的值标题。
  • Auto-toggle之间的观点。点击回收图标来打开和关闭自动切换。
    初始自动切换状态可以通过可选的卡片参数设置initial_auto_toggle_view。
    视图之间的时间段可以通过可选的卡片参数来设置auto_toggle_view_period.(以秒为单位)。

改进

  • 的性能。只更新有关的特定更改哈斯对象。
  • 不要压制太阳能、家用和电网图标上的零值;只有在箭头。
  • 在自述文件中有更多关于使用哪个传感器作为哪个卡参数的解释。

(目前还不支持向后计数的能量传感器。在这一点上还得再努力一点。)

动力轮卡仍处于测试阶段。您可以期待在未来的版本中发生破坏性的更改。

# 168

您有非常具体的图标着色请求。动力轮卡确实支持盒子中的一些。在潜入您的请求之前，让我们先向其他用户解释它们：

  • 你可以选择不给3个图标上色。使用color_icons:假这是默认的。
  • 你可以选择自动给它们上色。制作图标会变成绿色。消费图标会变成黄色。使用color_icons:真。
  • 你可以选择自己的颜色来生产和消费。使用consuming_color:和producing_color:为了那个原因。
  • 您可以在HA中设置一个主题，而动力轮卡将使用该主题——label-badge-yellow主题的颜色为黄色等自动。

您的着色请求超出了这些开箱即用的功能，不被支持。

然而，由于一些用户(例如您眨眼:)可以为其添加颜色传感器本身，我将以“让输入传感器的自定义颜色覆盖动力轮卡的颜色”为功能要求。就像图标一样。通过这种方式，高级用户可以非常明确地动态地为图标着色。你能举个例子说明如果有一个由其他组件动态设置的自定义颜色，实体属性会是什么样子吗?(顺便说一句，我不会马上着手开发这个功能，因为还有其他几个功能要先开发。)

# 169

不确定这是否是你的意思，但我使用模板传感器:

levering_of_verbruik：fullitical_name_template：> {％if状态（'sensor.netto_verbruik'）| int> 0％} verbruik {％eyls％} levering {％endif％} icon_template：> {％if状态（'sensor.netto_verbruik'）| int> 0％} MDI：导入{％ELES％％} MDI：导出{％ENDIF％} value_template：> {{sensor.netto_verbruik'）}}

我自定义如下：

sensor.levering_of_verbruik：endic_card_mode：徽章模板：＃icon_color：>＃if（state ==='杠杆'）返回'RGB（251,210,41）';＃返回'RGB（54,95,140）';主题：>如果（州> 0）返回'橙色';返回“绿色”;Unit_of_measurement：> $ {math.round（实体['sensor.calculd_bruto_verbruik']。状态）}

45

基于这些:

05

(实时更新引起的不同数字，能量流传感器尚未自定义着色)

如果我们可以设置这些自定义将是非常好的，但对于Home图标底部的右下角，这将是不可能的，因为卡片计算?

Home图标和我的(sh)自己的传感器一样。Levering_of_verbruik，但这并没有在配置实体中使用…

你可能会认为我有一个特殊的着色要求，但我觉得当你给它一些思考它是非常有用的。为所有实体设置一个默认设置并不能有效地处理纸牌，并且还会偏离其目的

# 170

当您在查找传感器时，属性看起来像什么/ dev - state页面?他们有颜色属性如?

# 171

一声对不起，没跟上……

不，我没有设置一个颜色的模板，但一个主题。当然也可以是一种颜色，即icon_color(参见我注释过的icon_color模板)。

这是dev-state:

{"friendly_name": "Verbruik"， "icon": "mdi:import"， "custom_ui_state_card": "state-card-custom-ui"， "state_card_mode": "badges"， "templates": {"theme": "if (state > 0) return 'orange';${Math.round(entities['sensor.calculated_bruto_verbruik'].state)}\n"}， "theme": "orange"， "unit_of_measurement": "444\n"}

顺便说一下，这是一个视图帽可能解释我的着色请求:

42

太阳产生时呈黄色(或活跃时呈灰色)

而返回网格是绿色的，从网格消费是红色的。

正如你所看到的，千瓦时和金钱相结合，非常有效。你的卡上也应该这样吧?

干杯!

# 172

那反相网格颜色?：祈祷：

# 173

单独的帖子，因为这可以为别人指出一些参考和使用。

只是模仿这一点，我认为基于NetTo Verbruik传感器定义生产和消费的各个实体的最紧凑方式：

{{[0，（'sensor.netto_verbruik'）| int | abs）] | max}}

这意味着我现在可以使用:

grid_power_consumption：friendly_name：网格功耗one_of_measurement：'watt'value_template：> {{[0，（'sensor.netto_verbruik'）| int | abs）| int | iss}} grid_power_production：friendment_name：网格电源生产Uner_of_measurement：'瓦'value_template：> {{[0，（'sensor.netto_verbruik'）| int | abs）] | max}}

代替

grid_power_consumption: friendly_name:电网电力消费unit_of_measurement:“瓦特”value_template: >{%如果各州(sensor.netto_verbruik) | int > 0%}{{州(sensor.netto_verbruik) | int}}{%其他%}0 {% endif %} grid_power_production: friendly_name:电网电力生产unit_of_measurement:“瓦特”value_template:{{(states('sensor.netto_verbruik')|int|abs)}} {% else %} 0 {% endif %}

或者更糟，当然这取决于你可用的传感器:

grid_power_production: friendly_name:目前的能源出口value_template: >{{[0,(状态(“sensor.zp_actuele_opbrengst”)| int -(“sensor.calculated_bruto_verbruik”)| int)] |马克斯}}unit_of_measurement:“瓦特”grid_power_consumption: friendly_name:“当前的能源进口”value_template:> {{[0， (states('sensor.calculated_bruto_verbruik') | int - states('sensor. zp_actuele_opbrenst ') | int)] | max}}
1像
# 174

差不多，但不完全是。因为现在你想用完全一样的value_template两个传感器。但我喜欢这个主意。你可以用最小值在后者，但不要忘记腹肌最后。

# 175

为什么?sensor.netto_verbruik显示了消费时的正用法，返回时的负用法。
使用一个| abs在正值上没有任何作用，并且在负面上，这使得它是正面的，就像卡所需的那样。

但是我看到我必须添加一个条件，否则两者的值总是相同的…

1像