:fill(white):strip_exif()/i/2006976478.jpeg?f=thumbmini)
@Maardiweb Hier ook een N100 gebruiker in de vorm van een Firebat. Zwakste onderdeel is wat ik lees de SSD. Dus die is nog wel een keer te vervangen, eventueel preventief.
Voor de mensen die HASS watervrees hebben, heeft HASS OS zelfs een versie voor de RPI2 in no time running is. Ik heb deze maandenlang zonder problemen laten draaien. Ben ondertussen feilloos gemigreerd naar de RPI5. Toch wel een groot verschil qua snelheid:
Ik lees regelmatig negatieve verhalen over een bepaalde hard- en/of software setup. Wanneer het allemaal soepel loopt heeft iemand minder gauw de neiging dit ook te delen. Om die reden doe ik het toch maar even, bij mij werkt Home Assistant soepel met de volgende hardware:
Raspberry Pi 4 4gbZigbee dongle sonoff
- boot op een 250gb ssd (geen sd card)
42 Zigbee apparaten waaronder (293 entiteiten):
- Native ZHA protocol werkt (tegenwoordig wel) goed
Geen aparte hub van Hue of Tradfri of een ander merk in gebruik, home assistant doet al het werk.
- Hue lampen
- Hue dimmer knoppen
- Tradfri lampen
- Tradfri knoppen
- Deur sensors
- Beweging sensors
- Ledstrip controllers
- Osram, Innr en Ikea power switches
Ook verbonden en te bedienen zijn:En binnen HA o.a. ook de volgende diensten werkend:
- Sonos zoneplayer Amp
- Reolink camera's (3 stuks)
- Fritzbox router/modem
- Google Chromecast Android TV
Ongeveer 100 automatiseringen zijn actief.
- Jellyfin - media Server (ipv Plex) - de media zelf staat op een aparte OMV NAS
- Adguard Home - dns server
Of dit systeem heel veel meer aan kan weet ik uiteraard niet, maar bovenstaande setup draait heel soepel.
Ben benieuwd naar vergelijkbare setups.
/u/298857/crop6471d9676d431.png?f=community)
:
[...]
offtopic:
Weet je toevallig ook het verbruik (liefst van het kale systeem zonder VMs etc, maar dat kun je nu natuurlijk niet meer meten), en zou je dat kunnen delen in Het grote zuinige server topic - deel 3 ?
Overigens is deze link ook al voldoende, zonder alle tracking meuk: https://nl.aliexpress.com/item/1005005468230829.html
offtopic:
Ik heb nog een andere N100 waar alleen Debian op staat die kan ik van het weekend wel even aan een slimme stekkker hangen. Alleen heeft die 8 GB en 256GB SSD dus niet honderd procent vergelijkbaar maar close.
Ik had geprobeerd de link op te schonen maar dan werkte ie niet meer en ik had haast. Ik zie nu hoe Septillion het gedaan heeft dus nu weet ik het voor de volgende keer.
Ik heb nog een andere N100 waar alleen Debian op staat die kan ik van het weekend wel even aan een slimme stekkker hangen. Alleen heeft die 8 GB en 256GB SSD dus niet honderd procent vergelijkbaar maar close.
Ik had geprobeerd de link op te schonen maar dan werkte ie niet meer en ik had haast. Ik zie nu hoe Septillion het gedaan heeft dus nu weet ik het voor de volgende keer.
offtopic:
Wel hetzelfde systeem? Want er zit AFAIK nogal wat variatie in. Sommige N100 systemen komen onder de 5W terwijl anderen niet onder de 8W komen.
Wel hetzelfde systeem? Want er zit AFAIK nogal wat variatie in. Sommige N100 systemen komen onder de 5W terwijl anderen niet onder de 8W komen.
Gewoon alles verwijderen na de ".html"
Zijn er hier meer mensen die zowel een aardig netwerk Zwave als Zigbee hebben?
Ik heb het idee dat ik steeds meer "storing" krijg in mijn netwerk(en). Meer op Zigbee dan op Zwave.
Ik heb ca 30 z-wave devies en ca 30 zigbee devices. Van beide zijn er een stuk of 5 die "gekoppeld" zijn maar ergens nog in een doos zitten
Dat kan een smart-plug zijn als een PIR/remote.
Setup:
Raspberry PI 4 met Sonoff Zigbee dongel en een Aotec Z-Stick
Zwave:
Hier heb ik 2 problemen. Probleem 1 is dat sommige devices wel eens "offline" gaan (node: dead). Druk ik in HA op "ping" is hij meteen weer online. Vaak bij de trap verlichting, midden in het huis zo ongeveer het meest dichtbij de PI. Waarom die 'dead' raakt snap ik niet en een ping lost het op. Maar een HA schakel-actie van die lap failt dus want hij is "dead"
Ander probleem is de buitenverlichting. Houten schuurtje met een Fibaro dimmer. Deze gaat vaak offline. Sure zit een meter of 8 tussen voor het huis en dat is natuurlijk beton en/of glas. Even een extra smartplug geplaatst in huis dus het is echt alleen dat aan materiaal. Ik kijk wel eens bij "last working route" en soms zie ik dat hij zelfs een connectie heeft via een plug die helemaal aan de andere kant van het huis hangt. En toch is deze ook vaak offline.
Zigbee (vooral verlichting):
Hier heb ik eigenlijk bijna altijd het probleem dat het "traag" reageert. Bij Z-wave is het vrijwel instant bij zigbee duurt het toch meestal 2~3 seconden.
En ook hier wat devices die het vaker niet doen dan wel.
Eglo zigbee spot RGB GUI10. Heb er een aantal binnen in huis tegen de buitenmuur/openslaande deur. En een paar buiten ook weer direct tegen de openslaande deur onder overstek. Daar zit dus nog geen 50 centimeter tussen. Ok het is HR glas en/of beton maar die spotjes buiten zijn vaker niet te bedienen dan wel. Mijn gevoel zegt me toch omdat het een mesh netwerk maakt dat dat echt perfect zou moeten werken over die afstand.
Misschien dat Z-wave en Zigbee elkaar storen? Vroeger had ik eigenlijk alleen Z-wave maar veel verlichting zie je alleen in Zigbee dus dat netwerk groeit. Meer mensen soortgelijke ervaringen? Het is echt lastig om te debuggen, soms werkt het prefect, soms werkt het totaal niet terwijl er dan aan het netwerk echt niks is veranderd. Soms zet ik een lamp aan via HA, de lamp gaat aan en 2 sec later is die node "dead". Druk ik op ping is hij meteen weer "alive".
Of kan het zo zijn dat als je devices in je netwerk hebt maar die zijn offline (liggen in een doos) dat er toch geprobeerd wordt (via) die devices te communiceren?
Ik heb het idee dat ik steeds meer "storing" krijg in mijn netwerk(en). Meer op Zigbee dan op Zwave.
Ik heb ca 30 z-wave devies en ca 30 zigbee devices. Van beide zijn er een stuk of 5 die "gekoppeld" zijn maar ergens nog in een doos zitten
Dat kan een smart-plug zijn als een PIR/remote.Setup:
Raspberry PI 4 met Sonoff Zigbee dongel en een Aotec Z-Stick
Zwave:
Hier heb ik 2 problemen. Probleem 1 is dat sommige devices wel eens "offline" gaan (node: dead). Druk ik in HA op "ping" is hij meteen weer online. Vaak bij de trap verlichting, midden in het huis zo ongeveer het meest dichtbij de PI. Waarom die 'dead' raakt snap ik niet en een ping lost het op. Maar een HA schakel-actie van die lap failt dus want hij is "dead"
Ander probleem is de buitenverlichting. Houten schuurtje met een Fibaro dimmer. Deze gaat vaak offline. Sure zit een meter of 8 tussen voor het huis en dat is natuurlijk beton en/of glas. Even een extra smartplug geplaatst in huis dus het is echt alleen dat aan materiaal. Ik kijk wel eens bij "last working route" en soms zie ik dat hij zelfs een connectie heeft via een plug die helemaal aan de andere kant van het huis hangt. En toch is deze ook vaak offline.
Zigbee (vooral verlichting):
Hier heb ik eigenlijk bijna altijd het probleem dat het "traag" reageert. Bij Z-wave is het vrijwel instant bij zigbee duurt het toch meestal 2~3 seconden.
En ook hier wat devices die het vaker niet doen dan wel.
Eglo zigbee spot RGB GUI10. Heb er een aantal binnen in huis tegen de buitenmuur/openslaande deur. En een paar buiten ook weer direct tegen de openslaande deur onder overstek. Daar zit dus nog geen 50 centimeter tussen. Ok het is HR glas en/of beton maar die spotjes buiten zijn vaker niet te bedienen dan wel. Mijn gevoel zegt me toch omdat het een mesh netwerk maakt dat dat echt perfect zou moeten werken over die afstand.
Misschien dat Z-wave en Zigbee elkaar storen? Vroeger had ik eigenlijk alleen Z-wave maar veel verlichting zie je alleen in Zigbee dus dat netwerk groeit. Meer mensen soortgelijke ervaringen? Het is echt lastig om te debuggen, soms werkt het prefect, soms werkt het totaal niet terwijl er dan aan het netwerk echt niks is veranderd. Soms zet ik een lamp aan via HA, de lamp gaat aan en 2 sec later is die node "dead". Druk ik op ping is hij meteen weer "alive".
Of kan het zo zijn dat als je devices in je netwerk hebt maar die zijn offline (liggen in een doos) dat er toch geprobeerd wordt (via) die devices te communiceren?
3780wP (18x 210wP EC Solar) | 2x Marstek Venus E (5.12kWh)
@virtualjoe In de basis is het zo simpel als je backup terug zetten en je nieuwe device zelfde vaste IP te geven. Enige waar je op moet letten zijn zaken die je via een dongle hebt draaien. Als je bijvoorbeeld van Zigbee controller wilt moet je even kijken of dat kan zonder re-pairen.
offtopic:
Grappig dat er juist ook nog mensen terug willen
Grappig dat er juist ook nog mensen terug willen
[ Voor 10% gewijzigd door Septillion op 27-09-2024 10:40 ]
:strip_icc():strip_exif()/u/845047/crop60d73a06c10a5_cropped.jpg?f=community)
/u/28836/crop61ee9dac0811d_cropped.png?f=community)
/u/320687/crop590915616a5bc_cropped.png?f=community)
/u/69548/crop68fb32f02f25b_cropped.png?f=community)
Ah joh verrek! Ergens wist ik dat wel maar even niet bij stil gestaan
Dan is dat het in elk geval niet.Ben nu niet thuis maar ik weet niet of je het hier aan kan zien?
code:
1
2
3
4
5
6
7
8
9
10
11
| DEVLINKS: >- /dev/serial/by-id/usb-ITEAD_SONOFF_Zigbee_3.0_USB_Dongle_Plus_V2_20240220115310-if00 /dev/serial/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.4:1.0 /dev/serial/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usbv2-0:1.4:1.0 DEVNAME: /dev/ttyACM0 DEVPATH: >- /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.4/1-1.4:1.0/tty/ttyACM0 ID_BUS: usb ID_MODEL: SONOFF_Zigbee_3.0_USB_Dongle_Plus_V2 ID_MODEL_ENC: SONOFF\x20Zigbee\x203.0\x20USB\x20Dongle\x20Plus\x20V2 ID_MODEL_ID: 55d4 |
Als ik even zoek lijkt dit de "E" versie te zijn. Hoe de firmware van deze is durf ik niet te zeggen. Van de z-wave stick wel een keer geupdated toen ik van een Pi3 naar een Pi4 ging, daar was iets met de compabiliteit.
Voor Z-wave indderdaad "Z-Wave JS", en voor zigbee "ZHA".
Yes nu ik door heb dat zigbee op 2.4ghz zit snap ik dat er meer verstoring kan zijn. Maar de meest slechte case zijn de spotjes. Daar zit echt nog geen 50cm tussen (sure wel glas en/of beton) dus daar kan toch geen 2.4ghz verstoring echt tussen zitten op zo'n afstand.
3780wP (18x 210wP EC Solar) | 2x Marstek Venus E (5.12kWh)
:strip_icc():strip_exif()/u/567214/crop60759ec284fe4_cropped.jpg?f=community)
:strip_icc():strip_exif()/u/1244740/crop619835423e299_cropped.jpg?f=community)
Dit is een mooie oplossing voor m’n andere hue lampen
Ik wist niet dat er een dergelijke gira schakelaar bestond. Thnx
Ik heb er 2 in de woonkamer, daar dim ik 6 lampen mee en schakel ik de buitenverlichting.
in de slaapkamer aan iedere zijde van het bed voor verlichting slaapkamer en alles uit functie
De wippers staan in de middenstand en kan je omhoog en omlaag drukken, dus het ziet er vlak uit.
Het mooie van deze oplossing t.o.v. de gira en jung (dure!) tastdrukkers is ook dat deze pulsdrukker niet zo'n luid klikgeluid maakt bij bediening.
in de slaapkamer aan iedere zijde van het bed voor verlichting slaapkamer en alles uit functie
De wippers staan in de middenstand en kan je omhoog en omlaag drukken, dus het ziet er vlak uit.
Het mooie van deze oplossing t.o.v. de gira en jung (dure!) tastdrukkers is ook dat deze pulsdrukker niet zo'n luid klikgeluid maakt bij bediening.
[ Voor 39% gewijzigd door Baxke op 28-09-2024 08:12 ]
Ik heb iets vaags met mijn AppleTV. Ik krijg continu de volgende regels in mijn log:
:fill(white):strip_exif()/f/image/UoaHKO20uz1nHJ8FfOknhzoP.png?f=user_large)
De AppleTV is bedraad aangesloten, maar het lijkt alsof hij ook continu met wifi contact wilt maken. Jullie een idee, want zo loopt mijn log aardig vol :-)
De AppleTV is bedraad aangesloten, maar het lijkt alsof hij ook continu met wifi contact wilt maken. Jullie een idee, want zo loopt mijn log aardig vol :-)
:strip_icc():strip_exif()/u/33909/crop5f4d2e6650311_cropped.jpeg?f=community)
:strip_icc():strip_exif()/u/1894616/crop685afccdcfd37_cropped.jpg?f=community)
Wat gaat er mis op de vroege ochtend. Ik wil de zonneopwek via een naald meter aangeven. De minimale opbrengst is 0. Maximaal 3500. Waarom begint de meter rechts in de hoek i.p.v. links in de hoek en werkt zich naar rechts gedurende de dag. Er staat een min teken voor maar toch krijg ik het niet gefixed. Zie hem echt ff niet ;-):strip_exif()/f/image/1ekh8zPPApigqpl0PJaJUa1I.jpg?f=fotoalbum_large)
:strip_exif()/f/image/yIY7Vc34jYjqg9d6Dfp89sna.jpg?f=fotoalbum_large)
:no_upscale():strip_icc():fill(white):strip_exif()/f/image/1ekh8zPPApigqpl0PJaJUa1I.jpg?f=user_large)
:no_upscale():strip_icc():fill(white):strip_exif()/f/image/yIY7Vc34jYjqg9d6Dfp89sna.jpg?f=user_large)
Denk in kansen, niet in problemen. Homewizard Plug-In Battery 5.4 kWh. Zendure 2400 AC 17.2 kWh. 3330 Wp zonnepanelen. EV 77 kWh. Peblar Business Laadpaal.
2/1-kap 1988 | Extra vloer en muurisolatie | HR++ glas | WTW: Duco Energie Comfort 325 2-zones | WP: Adlar II 6kW | CV wonen: Jaga Strada Hybrid DBH, slapen: traditionele radiatoren | Solar: Enphase oost/west/zuid 4.2kVA | Homeassistant
/u/275760/crop5da9b701a185c_cropped.png?f=community)
Denk in kansen, niet in problemen. Homewizard Plug-In Battery 5.4 kWh. Zendure 2400 AC 17.2 kWh. 3330 Wp zonnepanelen. EV 77 kWh. Peblar Business Laadpaal.
:strip_icc():strip_exif()/u/2011040/crop67a79969e2ddb.jpg?f=community)
Als je de meterstand ergens gebruikt, zul het verschil tussen de nieuwe en oude waarde eenmalig moeten corrigeren. In de historie zul je een sprong zien. Inderdaad heb je een dag een rare waarde die je eventueel kunt aanpassen in de statistics.
:no_upscale():strip_icc():fill(white):strip_exif()/f/image/2ceh0vpagYB9lSBm5UFaJtkI.jpg?f=user_large)
LG (AWHP R32) / ESPhome (ESP32) / GoodWe 4K-DT (5kWp) / Homewizard (1 PiB) / Home Assistant (NUC)
Zo simpel kan het zijn, dankjewel voor het duwtje in de juiste richting. Heb een template helper aangemaakt die de attribute current_position van een raam geeft. Kan ik mooi in de gaten houden wat die Velux ramen uit zichzelf doen
vw id.7 tourer pro s | evcc | holtkamper aero | fiscalist & prutser
:strip_exif()/u/17028/ico_sphere.gif?f=community)
Iemand die een Aqara T1 Leak Sensor al eens gebruikt ? Ik heb er eentje gekocht en deze lijkt niets te doen.
Batterij al vervangen maar geen LED. Deze zou een blauwe LED hebben die zichtbaar is als je hem reset/verbindt door hem 5 sec ingedrukt te houden, maar dat doet niets. Ook ZHA ziet em niet met scannen.
Batterij al vervangen maar geen LED. Deze zou een blauwe LED hebben die zichtbaar is als je hem reset/verbindt door hem 5 sec ingedrukt te houden, maar dat doet niets. Ook ZHA ziet em niet met scannen.
:strip_exif()/u/101588/the_lemmings_masacre_2_by_wormthingy.gif?f=community)
Vorige maand schreef ik over een bug in de Z-WaveJS integratie die het onmogelijk maakt om voor bepaalde producten de correcte setpoint in te stellen. Een van deze producten is mijn Popp TRV. Deze TRV heeft een range van 4-28°C (datasheet) maar rapporteert dit niet. Voor zover ik begreep was dit vroeger toegestaan in de Z-Wave spec, maar inmiddels niet meer en moet dit in de metadata meegegeven worden.
Omdat Home Assistant sinds 2024.8 temperaturen valideert is het dus voor mij onmogelijk om de volledige setpoint range te gebruiken. Tot die versie gebeurde de validatie alleen in de frontend en was dit aan te passen met een customization. Maar inmiddels dus niet meer. Het gebruik van de volledige range is voor mij belangrijk omdat deze TRV tevens geen 'Uit' functie heeft. 4°C is de laagste temperatuur die ik kan instellen en in combinatie met open ramen is dit soms ook nodig. Als een soort van pseudo-uit functie.
Gisteren had een user op GitHub een PR ingediend om deze bug op te lossen, maar helaas is deze PR direct (en IMHO nogal lomp) afgeschoten. Met als opmerking dat dit een device / integratie issue is en dat het daar opgelost moet worden. Ik snap dat prima, maar ik vind er nogal wat van dat iets wat jaren prima heeft gewerkt zonder enige vooraankondiging ineens niet meer werkt. Er is ook maar letterlijk één regel tekst aan besteedt in de release notes van augustus.
Vooralsnog heb ik maar een workaround gemaakt omdat toch de verwarming in mijn woning afhankelijk is van 8 van deze TRV's
. Aangezien ik toch met thermostaatmodi werk (Comfort, Eco, Thuis, Nacht, Afwezig en Uit) zet ik op de achtergrond nu maar de temperatuur door middel van Z-Wave commando:
Dan kan ik in ieder geval rondom deze change heen werken. Ik kan het namelijk niet verkopen dat de verwarming minimaal 2 maanden niet meer werkt
. Immers is er uiteraard nog geen fix voor de release van oktober en ik twijfel oprecht ook voor de release van november.
In de tussentijd wil ik nog wel kijken of ik eventueel met eigen Z-Wave JS configuratiebestanden metadata kan toevoegen aan deze knoppen. Hoe dat moet weet ik niet, maar misschien is het niet al te moeilijk
.
Omdat Home Assistant sinds 2024.8 temperaturen valideert is het dus voor mij onmogelijk om de volledige setpoint range te gebruiken. Tot die versie gebeurde de validatie alleen in de frontend en was dit aan te passen met een customization. Maar inmiddels dus niet meer. Het gebruik van de volledige range is voor mij belangrijk omdat deze TRV tevens geen 'Uit' functie heeft. 4°C is de laagste temperatuur die ik kan instellen en in combinatie met open ramen is dit soms ook nodig. Als een soort van pseudo-uit functie.
Gisteren had een user op GitHub een PR ingediend om deze bug op te lossen, maar helaas is deze PR direct (en IMHO nogal lomp) afgeschoten. Met als opmerking dat dit een device / integratie issue is en dat het daar opgelost moet worden. Ik snap dat prima, maar ik vind er nogal wat van dat iets wat jaren prima heeft gewerkt zonder enige vooraankondiging ineens niet meer werkt. Er is ook maar letterlijk één regel tekst aan besteedt in de release notes van augustus.
Vooralsnog heb ik maar een workaround gemaakt omdat toch de verwarming in mijn woning afhankelijk is van 8 van deze TRV's
. Aangezien ik toch met thermostaatmodi werk (Comfort, Eco, Thuis, Nacht, Afwezig en Uit) zet ik op de achtergrond nu maar de temperatuur door middel van Z-Wave commando:YAML:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
| - id: climate_thermostat_set_temperature alias: Klimaat - Thermostaat stel temperatuur in mode: restart variables: climate_entity: climate.my_climate_entity mode_entity: input_select.thermostat_mode_my_climate setpoint: >- {% if is_state(mode_entity, 'Comfort') %} 18.0 {% elif is_state(mode_entity, 'Eco') %} 17.0 {% elif is_state(mode_entity, 'Thuis') %} 16.0 {% elif is_state(mode_entity, 'Nacht') %} 15.0 {% elif is_state(mode_entity, 'Afwezig') %} 12.0 {% else %} 4.0 {% endif %} trigger: - platform: state entity_id: input_select.thermostat_mode_my_climate - platform: homeassistant event: start action: repeat: while: "{{ not is_state_attr(climate_entity, 'temperature', setpoint) and repeat.index <= 6 }}" sequence: - action: zwave_js.set_value target: entity_id: "{{ climate_entity }}" data: command_class: "67" property: setpoint-1 value: "{{ setpoint | float(0) }}" - wait_template: "{{ is_state_attr(climate_entity, 'temperature', setpoint) }}" timeout: minutes: 5 - if: - "{{ not wait.completed and repeat.index > 5 }}" then: action: notify.phones data: title: "Probleem met {{ state_attr(climate_entity, 'friendly_name') }}" message: "Temperatuur {{ setpoint }} kon niet ingesteld worden." data: ttl: 0 priority: high push: sound: name: "default" critical: 1 volume: 0 |
Dan kan ik in ieder geval rondom deze change heen werken. Ik kan het namelijk niet verkopen dat de verwarming minimaal 2 maanden niet meer werkt
. Immers is er uiteraard nog geen fix voor de release van oktober en ik twijfel oprecht ook voor de release van november.In de tussentijd wil ik nog wel kijken of ik eventueel met eigen Z-Wave JS configuratiebestanden metadata kan toevoegen aan deze knoppen. Hoe dat moet weet ik niet, maar misschien is het niet al te moeilijk
.
Denk in kansen, niet in problemen. Homewizard Plug-In Battery 5.4 kWh. Zendure 2400 AC 17.2 kWh. 3330 Wp zonnepanelen. EV 77 kWh. Peblar Business Laadpaal.
Van mijn vriendin kon ik niet op veel enthousiasme rekenen om dit te delen dus ik hoop dat ik hier een betere doelgroep te vinden. Ben ik de enige met behoefte aan dit soort widgets? Ik merk dat ik nu nog afhankelijk ben van de HomeWizard app omdat er handige widgets tussen zitten die home assistant niet ondersteund.
Ik ben nu bezig om een eerste te proberen toe te voegen aan de iOS app. Best een leuke uitdaging zonder iOS ervaring. Fetched automatisch de beschikbare sensors in HA en weergeeft de state met eventuele measurement unit.
:strip_exif()/f/image/ahEL53NyAzc7WVGcUUOc81to.jpg?f=fotoalbum_large)
Ik ben nu bezig om een eerste te proberen toe te voegen aan de iOS app. Best een leuke uitdaging zonder iOS ervaring. Fetched automatisch de beschikbare sensors in HA en weergeeft de state met eventuele measurement unit.
:no_upscale():strip_icc():fill(white):strip_exif()/f/image/ahEL53NyAzc7WVGcUUOc81to.jpg?f=user_large)
Denk in kansen, niet in problemen. Homewizard Plug-In Battery 5.4 kWh. Zendure 2400 AC 17.2 kWh. 3330 Wp zonnepanelen. EV 77 kWh. Peblar Business Laadpaal.
:strip_icc():strip_exif()/u/114280/web.jpg?f=community)
:strip_icc():strip_exif()/u/137578/crop684839b85b72a.jpg?f=community)
:strip_exif()/u/618019/crop67d6d4a4200e7_cropped.webp?f=community)
Iemand enig idee?
Ik ben nog steeds bezig met een dashboard voor m'n tablet maar wil graag 3 of 4 kolommen maar wil graag de eerste kolom smaller hebben hoe kan ik dit aanpassen?
:strip_exif()/f/image/xJHIPfy4t3MPQSmF8wlfuY5F.jpg?f=fotoalbum_large)
Ik zie nergens een optie hiervoor of is het niet mogelijk?
Ik ben nog steeds bezig met een dashboard voor m'n tablet maar wil graag 3 of 4 kolommen maar wil graag de eerste kolom smaller hebben hoe kan ik dit aanpassen?
:no_upscale():strip_icc():fill(white):strip_exif()/f/image/xJHIPfy4t3MPQSmF8wlfuY5F.jpg?f=user_large)
Ik zie nergens een optie hiervoor of is het niet mogelijk?
@alex3305 Nouwja, het is een functie van HA die er al tijden in zat. Dat WAS de overgangsperiode. En zoals je merkt, zolang het niet enforced is vormt het geen probleem en is er dus ook voor niemand de incentive dit op te lossen...
HA stelt namelijk al tijden dat een min en max opgegeven kunnen worden en anders zal de default van 7 t/m 35 graden gelden. Is er breder nodig dan was het altijd al aan de integratie om dat correct aan te geven.
Dus mja, kan me voorstellen dat het wat lomp klinkt maar het via de customize oplossen is weer een "smerige" work around. De enige correct manier is dus dat dit correct uit de integratie vloeit. Was het netter geweest dat dit wat explicieter aangegeven was, absoluut. Maar doet voor nu dus niets af aan de correct oplossing
HA stelt namelijk al tijden dat een min en max opgegeven kunnen worden en anders zal de default van 7 t/m 35 graden gelden. Is er breder nodig dan was het altijd al aan de integratie om dat correct aan te geven.
Dus mja, kan me voorstellen dat het wat lomp klinkt maar het via de customize oplossen is weer een "smerige" work around. De enige correct manier is dus dat dit correct uit de integratie vloeit. Was het netter geweest dat dit wat explicieter aangegeven was, absoluut. Maar doet voor nu dus niets af aan de correct oplossing
Ik heb op dit moment verschillende shortcuts om Bumba (via YouTube) af te spelen op de Apple TV. Dat werkt via de volgende code:
Nu heb ik dus verschillende shortcuts/buttons die allemaal naar verschillende Bumba-compilaties verwijzen. Nu vraag ik me af: kan ik één shotcut/button maken die een random YouTube-linkje kiest (uiteraard ergens zelf ingevoerd) en die dan richting de Apple TV verstuurt?
/f/image/t6L1SmnADnwIRpx0tspoi1aL.png?f=fotoalbum_large)
YAML:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| - type: custom:mushroom-template-card primary: Bumba secondary: Compilatie 2 icon: '' entity: media_player.apple_tv tap_action: action: perform-action perform_action: media_player.play_media target: entity_id: - media_player.apple_tv data: media_content_type: url media_content_id: youtube://www.youtube.com/watch?v=AOIxB17mZhA |
Nu heb ik dus verschillende shortcuts/buttons die allemaal naar verschillende Bumba-compilaties verwijzen. Nu vraag ik me af: kan ik één shotcut/button maken die een random YouTube-linkje kiest (uiteraard ergens zelf ingevoerd) en die dan richting de Apple TV verstuurt?
:fill(white):strip_exif()/f/image/t6L1SmnADnwIRpx0tspoi1aL.png?f=user_large)
[ Voor 8% gewijzigd door dannyvdb1997 op 29-09-2024 15:11 ]
:strip_icc():strip_exif()/u/85246/alterbirdgeblackbirdsmall.jpg?f=community)
@Verwijderd Stap 1, backup
Maar al je energy dashboard stats zoals zitten al in de long term stats van de HA database. Deze gaan nooit vanzelf weg en zijn niet beïnvloed door purge_keep_days. Dit zijn per uur samenvattingen van de data en enige dat energy dashboard gebruikt en voor de meeste mensen ook fijn genoeg qua details. Dit zal bijgehouden worden voor alle entiteiten die een state_class hebben.
Daarnaast is data naar InfluxDB sturen ook alleen een real time event. Dus HA stuurt het zodra de data binnen komt en daarna nooit meer. Dus HA database aanpassen zal daar ook geen verandering in aanbrengen.
Je kan dus rustig purge_keep_days gewoon weer op de standaard 10 dagen zetten. InfluxDB zal dan nog bewaren wat je daarheen stuurt en energy dashboard blijft gewoon werken uit de LTS. Want HA is ook gewoon niet gebouwd om alle states oneindig / zo lang te bewaren.
Maar al je energy dashboard stats zoals zitten al in de long term stats van de HA database. Deze gaan nooit vanzelf weg en zijn niet beïnvloed door purge_keep_days. Dit zijn per uur samenvattingen van de data en enige dat energy dashboard gebruikt en voor de meeste mensen ook fijn genoeg qua details. Dit zal bijgehouden worden voor alle entiteiten die een state_class hebben.
Daarnaast is data naar InfluxDB sturen ook alleen een real time event. Dus HA stuurt het zodra de data binnen komt en daarna nooit meer. Dus HA database aanpassen zal daar ook geen verandering in aanbrengen.
Je kan dus rustig purge_keep_days gewoon weer op de standaard 10 dagen zetten. InfluxDB zal dan nog bewaren wat je daarheen stuurt en energy dashboard blijft gewoon werken uit de LTS. Want HA is ook gewoon niet gebouwd om alle states oneindig / zo lang te bewaren.
Verwijderd
Thanks. Dat klinkt logisch.:
@Verwijderd Stap 1, backup
Maar al je energy dashboard stats zoals zitten al in de long term stats van de HA database. Deze gaan nooit vanzelf weg en zijn niet beïnvloed door purge_keep_days. Dit zijn per uur samenvattingen van de data en enige dat energy dashboard gebruikt en voor de meeste mensen ook fijn genoeg qua details. Dit zal bijgehouden worden voor alle entiteiten die een state_class hebben.
Daarnaast is data naar InfluxDB sturen ook alleen een real time event. Dus HA stuurt het zodra de data binnen komt en daarna nooit meer. Dus HA database aanpassen zal daar ook geen verandering in aanbrengen.
Je kan dus rustig purge_keep_days gewoon weer op de standaard 10 dagen zetten. InfluxDB zal dan nog bewaren wat je daarheen stuurt en energy dashboard blijft gewoon werken uit de LTS. Want HA is ook gewoon niet gebouwd om alle states oneindig / zo lang te bewaren.
Backups worden 2x per dag gemaakt. Vandaar dat het mij opviel, de storage liep nogal gauw vol van mijn backup device. ;-)
Heb 't aangepast, maar zie nu verder niks gebeuren qua DB omvang. Vermoed dat ik (of HA) nog wat moet aftrappen hiervoor...?
/u/196426/crop63b7f3e4ad5a2_cropped.png?f=community)
:strip_icc():strip_exif()/u/1569106/crop60feb2bf05327_cropped.jpg?f=community)
Ik zie dat toch echt anders. Eerder was het zo dat er alleen in de frontend gecontroleerd werd of een ingestelde temperatuur binnen een range viel. Customize was daarbij de enige juiste oplossing om hier omheen te werken. Immers was het alleen een frontend beperking. In augustus wordt het ineens echter een harde beperking zonder vooraankondiging of waarschuwingen. Het werkt simpelweg niet meer. Dat verdient op z'n zachtst gezegd niet de schoonheidsprijs. En de waardes 7-35 zijn natuurlijk arbitrair.:
@alex3305 Nouwja, het is een functie van HA die er al tijden in zat. Dat WAS de overgangsperiode. En zoals je merkt, zolang het niet enforced is vormt het geen probleem en is er dus ook voor niemand de incentive dit op te lossen...
HA stelt namelijk al tijden dat een min en max opgegeven kunnen worden en anders zal de default van 7 t/m 35 graden gelden. Is er breder nodig dan was het altijd al aan de integratie om dat correct aan te geven.
Dus mja, kan me voorstellen dat het wat lomp klinkt maar het via de customize oplossen is weer een "smerige" work around. De enige correct manier is dus dat dit correct uit de integratie vloeit. Was het netter geweest dat dit wat explicieter aangegeven was, absoluut. Maar doet voor nu dus niets af aan de correct oplossing
Overigens heb ik deze vraag inmiddels neergelegd bij Z-Wave JS en daar reageerde de hoofdontwikkelaar en tevens medewerker van Nabu Casa dat hij dit intern gaat bespreken. Maar ook dat deze validatie tegen de Z-Wave spec is:
:fill(white):strip_exif()/f/image/dfg55Bqkcs2IhNt5orUfqISr.png?f=user_large)
IMHO zou de oplossing wellicht heel eenvoudig kunnen zijn voor Z-Wave devices, namelijk alleen maar valideren op een getal. En in de praktijk zou dat dan wellicht een standaard range van 0-99 of 1-99 kunnen zijn. Dan zijn er ook geen edge-cases meer.
:strip_icc():strip_exif()/u/109144/IMG_2440.jpg?f=community)
@alex3305 Ik ben het met je eens dat het geen schoonheidprijs verdient dat dit niet met een officiële depecated is aangegeven 
Dus tijdelijke terugdraai zodat de integratie het kan oplossen had ik wel redelijk gevonden.
Maar als het een eis is vanuit Zwave dan is het 100% aan Zwave-JS om dat op te lossen. HA eist namelijk simpelweg anders. Dus is het aan de integratie om die twee eisen te verenigen. Het doet namelijk af aan de hele abstractie om in HA dat voor Zwave anders te doen.
Dus dan zou het voor Zwave JS een simpele oplossing zijn om dit dan als 0-99 of -40-40 ofzo te doen. Want je gaat mij niet vertellen dat je doodleuk tegen die TVR kunt zeggen dat hij op -9999999 moet en dat hij dat dan ook doet. Er zal toch echt ergens een hardware limiet zijn.
En strict genomen voldoet het dus ook nog gezien je het dus nog zwave_js.set_value kunt gebruiken
En tuurlijk, ik snap dat het niet wenselijk is en dat dit opgelost moet worden.
Dus tijdelijke terugdraai zodat de integratie het kan oplossen had ik wel redelijk gevonden.Maar als het een eis is vanuit Zwave dan is het 100% aan Zwave-JS om dat op te lossen. HA eist namelijk simpelweg anders. Dus is het aan de integratie om die twee eisen te verenigen. Het doet namelijk af aan de hele abstractie om in HA dat voor Zwave anders te doen.
Dus dan zou het voor Zwave JS een simpele oplossing zijn om dit dan als 0-99 of -40-40 ofzo te doen. Want je gaat mij niet vertellen dat je doodleuk tegen die TVR kunt zeggen dat hij op -9999999 moet en dat hij dat dan ook doet. Er zal toch echt ergens een hardware limiet zijn.
En strict genomen voldoet het dus ook nog gezien je het dus nog zwave_js.set_value kunt gebruiken
En tuurlijk, ik snap dat het niet wenselijk is en dat dit opgelost moet worden.
@Septillion De range tussen 7-35 is in dit geval wat ongelukkig.
Een range binnen het vries- en kookpunt van water lijkt mij niets meer dan redelijk voor thermostaten
.
De TRV geeft terug of de waarde correct ingesteld is. Dus als jij -999999 opgeeft en de vorige waarde was (bijvoorbeeld) 14.5 dan geeft de TRV 14.5 terug. Want -999999 is voor de TRV een ongeldige waarde.
Een range binnen het vries- en kookpunt van water lijkt mij niets meer dan redelijk voor thermostaten
.
@alex3305 Mja, het licht er heel sterk aan wat je wilt sturen natuurlijk. Default waardes zullen altijd wat arbitrary blijven.
Maar misschien mooie voor de integratie om dat de limieten op te zoeken tijden toevoegen. Kijken tot wanneer het device niet meer volgt
Maar misschien mooie voor de integratie om dat de limieten op te zoeken tijden toevoegen. Kijken tot wanneer het device niet meer volgt