Home Assistant - Open source Python3 home automation

[Rafael]

Bedankt voor de feedback @Martijn02 @Hmmbob en @Vanx. Ik ga er nog even over nadenken dan Vooral die website om subdomeinen te zoeken liet me even grote ogen trekken, ik heb nog subdomeinen actief staat die ik zelf al vergeten was blijkbaar

Voorlopig heb ik mijn issue dan maar opgelost met een Telegram bot, ook wel iets leuks om mee te spelen. Qua veiligheid kan die niet meer dan ik er zelf in programmeer, dat voldoet momenteel wel weer.

[Morpheusk]

Ik heb de volgende link gevolgd om de logfiles en database te verplaatsen naar usb.

Al deze stappen van https://blog.ceard.tech/2...ng-logs-and-database.html heb ik gevolgd. Bij de laatste stap heb ik een reboot gedaan, maar nu krijg ik het volgende.

service:
home-assistant@homeassistant: failed

Wat nu? Mijn linux kennis is nog vrij beperkt helaas.

aanvullende log

code:

pi@hassbian:/ $ sudo systemctl status [e-mail]
● [e-mail] - Home Assistant for homeassistant
   Loaded: loaded (/etc/systemd/system/[e-mail]; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Wed 2019-07-17 21:33:40 BST; 875ms ago
  Process: 832 ExecStart=/srv/homeassistant/bin/hass (code=exited, status=1/FAILURE)
 Main PID: 832 (code=exited, status=1/FAILURE)

Jul 17 21:33:39 hassbian hass[832]:     import homeassistant.helpers.config_validation as cv
Jul 17 21:33:39 hassbian hass[832]:   File "<frozen importlib._bootstrap>", line 983, in _find_and_load
Jul 17 21:33:39 hassbian hass[832]:   File "<frozen importlib._bootstrap>", line 967, in _find_and_load_unlocked
Jul 17 21:33:39 hassbian hass[832]:   File "<frozen importlib._bootstrap>", line 677, in _load_unlocked
Jul 17 21:33:39 hassbian hass[832]:   File "<frozen importlib._bootstrap_external>", line 724, in exec_module
Jul 17 21:33:39 hassbian hass[832]:   File "<frozen importlib._bootstrap_external>", line 857, in get_code
Jul 17 21:33:39 hassbian hass[832]:   File "<frozen importlib._bootstrap_external>", line 525, in _compile_bytecode
Jul 17 21:33:39 hassbian hass[832]: MemoryError
Jul 17 21:33:40 hassbian systemd[1]: [e-mail]: Main process exited, code=exited, status=1/FAILURE
Jul 17 21:33:40 hassbian systemd[1]: [e-mail]: Failed with result 'exit-code'.

[ Voor 66% gewijzigd door Morpheusk op 17-07-2019 22:34 ]

[ANdrode]

Vanx schreef op woensdag 17 juli 2019 @ 21:46:
[...]
Port scans draaien tegenwoordig op alle ports, en via iets als https://hackertarget.com/find-dns-host-records/ kan je zo alle subdomeinen vinden.

Is niet zo /heel/ betrouwbaar maar een leuke tool. Wanneer je SSL gebruikt zonder wildcard is crt.sh bijzonder effectief. Vrijwel 100% dekking voor de op dit moment geldige SSL certificaten.

offtopic:
Weet even niet wanneer de oudste certificaten zonder CT verlopen en of er nog CA's zijn die zonder issue-en

Hmmbob schreef op woensdag 17 juli 2019 @ 21:53:
Mijn Traefik gebruikt een wildcard certificate voor al mijn subdomeinen binnen mijn hoofdomein, dus die enumeratie gaat ook niet op.

Wildcard certificate is de beste optie. Enumeratie voorkomen is in mijn ogen écht vaker een voordeel daarvan dan de flexibiliteit die het biedt.

[martinvdm]

Rafael schreef op woensdag 17 juli 2019 @ 15:21:
Zijn er eigenlijk veel personen die hun Home Assistant met bvb Nginx aan het internet hebben hangen? Veel last van ongewenste bezoekers? Lijkt me soms wel interessant om o.a. de (binnen)temperaturen wat op te volgen vanop afstand.

Heb Træfik draaien en op Home assistant 2fa actief en ip ban.

[--WaaZaa--]

DeadMetal schreef op woensdag 17 juli 2019 @ 15:42:
[...]


Als je de cloud functionaliteit gebruikt, kan je hem niet met HA integreren. Vandaar de MQTT-setup.
Maar inderdaad wel zo praktisch om het eerst via de Shelly cloud app te testen voordat je moeite gaat doen om het aan HA toe te voegen.

/edit: het is trouwens of-of. Zodra je MQTT activeert in de webinterface van de Shelly, waarschuwt hij dat de cloud-functionaliteit uitgeschakeld zal worden.

Ik had MQTT draaien voor een enkele Shelly. Echter toen ik er meer moest toevoegen, MQTT eruit en deze erin via HACS: https://github.com/StyraHem/ShellyForHASS ideaal!

[RudolfR]

Hmmbob schreef op woensdag 17 juli 2019 @ 21:53:
True voor wat betreft schijnveiligheid (security by obscurity). Ik kan 443 echter niet gebruiken, daar draait mijn VPN op (ivm company firewall - je moet iets...)(en ja, via VPN zou ook kunnen /beter zijn, maar past niet bij al mijn use cases).

OpenVPN kan https-verkeer redirecten naar een andere host/port.
Of je kan er sslh tussen zetten.

Nadeel daarvan is dat al het verkeer dan vanuit de proxy lijkt te komen. Dus aan trusted-ips en/of fail2ban heb je dan niks meer. Tenzij je het transparant weet te proxy-en, maar daar ben ik nog niet in geslaagd.


@Rafael

Als het je alleen om de temperaturen gaat kun je die ook periodiek naar jezelf laten sturen via bijv. Telegram.

[Yukkie]

Home-Assistant 0.96 is uit: https://www.home-assistant.io/blog/2019/07/17/release-96/

Met zoals @Hmmbob hieronder terecht opmerkt een grote overhaul van het climat component. Wat mij vanmorgen opviel dat gebruikers van Opentherm_GW de config aan moeten passen: https://www.home-assistant.io/components/opentherm_gw/

Voorbeeld:

YAML:

Oud:
opentherm_gw:
  device: socket://1.0.0.1:6638
  climate:
    name: Thermostat
    precision: 0.5
    floor_temperature: true
  monitored_variables:
    - room_setpoint
    - room_temp
    - otgw_about

Nieuw:
opentherm_gw:
  thermostat:
    device: socket://1.0.0.1:6638
    name: "Thermostat"
    climate:
      precision: 0.5
      floor_temperature: true

Je er krijgt nu gratis en ongevraagd een hele bak sensors bij, die voor mij op dit moment overbodig zijn. Voor zover ik nu begrijp kun je niet zelf meer kiezen welke onderdelen je gemonitord wil hebben.

voorbeeld:

(en dit is nog niet eens alles)

Ik ben er niet zo blij mee eigenlijk

[ Voor 34% gewijzigd door Yukkie op 18-07-2019 08:24 ]

[Hmmbob]

RudolfR schreef op donderdag 18 juli 2019 @ 07:36:
OpenVPN kan https-verkeer redirecten naar een andere host/port.
Of je kan er sslh tussen zetten.

Die opties heb ik niet op de openvpn implementatie op mijn router

Yukkie schreef op donderdag 18 juli 2019 @ 08:13:
Home-Assistant 0.96 is uit: https://www.home-assistant.io/blog/2019/07/17/release-96/

Opentherm_GW gebruikers let op dat je je config aan moet passen: https://www.home-assistant.io/components/opentherm_gw/

Je krijgt nu gratis en ongevraagd een hele bak sensors, voor zover ik nu begrijp kun je niet zelf meer kiezen welke onderdelen je gemonitord wil hebben.
voorbeeld:

[Afbeelding: Openthem Gateway Sensoren]
(en dit is nog niet eens alles)

Ik ben er niet zo blij mee eigenlijk

Ik zie verder grote changes in alles wat met climate te maken heeft, en de ZHA implementatie.

[ Voor 15% gewijzigd door Hmmbob op 18-07-2019 08:21 ]

[JayOne]

Hmmbob schreef op donderdag 18 juli 2019 @ 08:17:
[...]
Die opties heb ik niet op de openvpn implementatie op mijn router


[...]

Ik zie verder grote changes in alles wat met climate te maken heeft, en de ZHA implementatie.

Die climate changes waren begin deze maand al aangekondigd (edit: die ook in de release-blog staat vermeld dus)

[ Voor 5% gewijzigd door JayOne op 18-07-2019 08:44 ]

[Frenck]

Home Assistant 0.96!

https://www.home-assistant.io/blog/2019/07/17/release-96/

[Martijn02]

Frenck schreef op donderdag 18 juli 2019 @ 10:32:
Home Assistant 0.96!

https://www.home-assistant.io/blog/2019/07/17/release-96/

Woot.. deze versie bevat de verbeteringen die ik aan het logbook heb gedaan!

Had een pull request ingeschoten om de weergave van binary_sensors in het logbook wat duidelijker te maken. (deuren en ramen gaan nu open en dicht in plaats van aan en uit)

[Frenck]

Martijn02 schreef op donderdag 18 juli 2019 @ 10:41:
[...]


Woot.. deze versie bevat de verbeteringen die ik aan het logbook heb gedaan!

Nice! Dat is inderdaad een welkome toevoeging!

[Yukkie]

Hmmm, volgens mij is er iets mis met het nieuwe Opentherm_gw component:

code:

2019-07-18 10:47:54 DEBUG (MainThread) [homeassistant.components.opentherm_gw] Received report: {'control_setpoint': 10.0, 'master_ch_enabled': 0, 'master_dhw_enabled': 1, 'master_cooling_enabled': 0, 'master_otc_enabled': 0, 'master_ch2_enabled': 0, 'slave_fault_indication': 0, 'slave_ch_active': 0, 'slave_dhw_active': 0, 'slave_flame_on': 0, 'slave_cooling_active': 0, 'slave_ch2_active': 0, 'slave_diagnostic_indication': 0, 'otgw_about': 'OpenTherm Gateway 4.2.5', 'otgw_build': '17:59 20-10-2015', 'otgw_clockmhz': '4 MHz', 'otgw_mode': 'G', 'otgw_smart_pwr': 'Low power', 'otgw_thermostat_detect': 'D', 'otgw_dhw_ovrd': 'A', 'otgw_setpoint_ovrd_mode': 'N', 'otgw_gpio_a': 0, 'otgw_gpio_b': 0, 'otgw_led_a': 'F', 'otgw_led_b': 'X', 'otgw_led_c': 'O', 'otgw_led_d': 'T', 'otgw_led_e': 'P', 'otgw_led_f': 'C', 'otgw_ignore_transitions': 1, 'otgw_ovrd_high_byte': 1, 'otgw_setback_temp': 16.0, 'otgw_vref': 3, 'remote_transfer_dhw': 0, 'remote_transfer_max_ch': 0, 'remote_rw_dhw': 0, 'remote_rw_max_ch': 0, 'slave_max_relative_modulation': 0.0, 'slave_max_capacity': 0, 'slave_min_mod_level': 0, 'room_setpoint': 16.0, 'relative_mod_level': 0.0, 'ch_water_pressure': 0.0, 'room_temp': 25.01953125, 'ch_water_temp': 0.0, 'dhw_temp': 0.0, 'outside_temp': 0.0, 'return_water_temp': 0.0, 'slave_dhw_max_setp': 0, 'slave_dhw_min_setp': 0, 'slave_ch_max_setp': 0, 'slave_ch_min_setp': 0, 'dhw_setpoint': 0.0, 'max_ch_setpoint': 90.0, 'burner_starts': 0, 'ch_pump_starts': 0, 'dhw_pump_starts': 0, 'dhw_burner_starts': 0, 'burner_hours': 0, 'ch_pump_hours': 0, 'dhw_pump_hours': 0, 'dhw_burner_hours': 0}
2019-07-18 10:47:54 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/usr/src/app/homeassistant/helpers/entity.py", line 226, in async_update_ha_state
    self._async_write_ha_state()
  File "/usr/src/app/homeassistant/helpers/entity.py", line 256, in _async_write_ha_state
    attr.update(self.state_attributes or {})
  File "/usr/src/app/homeassistant/components/climate/__init__.py", line 169, in state_attributes
    ATTR_HVAC_MODES: self.hvac_modes,
  File "/usr/src/app/homeassistant/components/climate/__init__.py", line 254, in hvac_modes
    raise NotImplementedError()
NotImplementedError

Volgens mij is mijn config wel goed toch?

YAML:

opentherm_gw:
  thermostat:
    device: socket://1.0.0.1:6638
    name: "Thermostat"
    climate:
      precision: 0.5
      floor_temperature: true

Ik heb wel die tientallen sensoren in HA, maar geen climate component

Is dit een bug of een configuratie fout?

[ANdrode]

Yukkie schreef op donderdag 18 juli 2019 @ 10:50:
Ik heb wel die tientallen sensoren in HA, maar geen climate component

Is dit een bug of een configuratie fout?

Grote kans op een bug doordat de test suite niet tegen implementaties van een class gedaan wordt en/of dat de default van een fout gooien onhandig gekozen is.

[Frenck]

Yukkie schreef op donderdag 18 juli 2019 @ 10:50:
Hmmm, volgens mij is er iets mis met het nieuwe Opentherm_gw component:

Ik heb wel die tientallen sensoren in HA, maar geen climate component

Is dit een bug of een configuratie fout?

Dat is absoluut een bug, open svp even een issue op onze GitHub:
https://github.com/home-assistant/home-assistant/issues

[Yukkie]

@Frenck Working on it

done

[ Voor 61% gewijzigd door Yukkie op 18-07-2019 11:11 ]

[sopi]

......

Ik heb wel die tientallen sensoren in HA, maar geen climate component

Is dit een bug of een configuratie fout?

Idem met rooted Toon geen climate.toon_thermostat component meer te vinden

[Frenck]

@sopi De climate basis van HA in 0.96 is compleet herschreven. Alle climate integraties zijn hierop aangepast. In het geval van rooted Toon, gaat het om een custom component. De betreffende auteur zal dus zijn custom integratie moeten updaten.

[sopi]

Frenck schreef op donderdag 18 juli 2019 @ 11:48:
@sopi De climate basis van HA in 0.96 is compleet herschreven. Alle climate integraties zijn hierop aangepast. In het geval van rooted Toon, gaat het om een custom component. De betreffende auteur zal dus zijn custom integratie moeten updaten.

Duidelijk

afwachten dan maar

Voor het overige niks anders dan lof voor HA, heb er heel veel plezier van

[kmf]

Hmmbob schreef op dinsdag 16 juli 2019 @ 20:21:
[...]

Tof, maar wat is precies het voordeel boven de standaard HA Zwave integratie, want die zie ik nog niet helemaal?

tdw schreef op dinsdag 16 juli 2019 @ 20:52:
[...]

MQTT is platformonafhankelijk. Zo draait het op oa. HA, maar ook op ESP8266's. Je zou dus een deel van je automations kunnen afvangen buiten HA om

Tassadar32 schreef op woensdag 17 juli 2019 @ 15:15:
@stijn1309 Ander alternatief is espHome wat ook op de shelly werkt. Geen MQTT broker nodig en werkt direct in HA.

Even inhakend hierop:
Het grote voordeel van MQTT is dat je onhafhankelijkheid creeert (behalve dan op MQTT)
Je kan dan met meerdere tools info en commando's delen en je bent niet langer gebonden aan 1 oplossing als HA. MQTT is dan ook maar een centrale punt.

In principe kan je dan makkelijk domoticz, HA, openHAB naast elkaar draaien. Qua integratie in HA is het dan ook een snap. Zeker met MQTT autodiscovery aan.

Ik gebruik bv een MagicMirror om MQTT weer te geven als data (mooi), Node-Red om automation flows te doen (makkelijk), en HA is een veredelde switchinterface om dingen aan/uit te zetten.

Juist vanwege MQTT gebruik ik espeasy/tasmota ipv esphome

[Yoki1985]

kmf schreef op donderdag 18 juli 2019 @ 12:03:
[...]


[...]


[...]


Even inhakend hierop:
Het grote voordeel van MQTT is dat je onhafhankelijkheid creeert (behalve dan op MQTT)
Je kan dan met meerdere tools info en commando's delen en je bent niet langer gebonden aan 1 oplossing als HA. MQTT is dan ook maar een centrale punt.

In principe kan je dan makkelijk domoticz, HA, openHAB naast elkaar draaien. Qua integratie in HA is het dan ook een snap. Zeker met MQTT autodiscovery aan.

Ik gebruik bv een MagicMirror om MQTT weer te geven als data (mooi), Node-Red om automation flows te doen (makkelijk), en HA is een veredelde switchinterface om dingen aan/uit te zetten.

Juist vanwege MQTT gebruik ik espeasy/tasmota ipv esphome

esphome kan ook perfect overweg met MQTT. Deze worden dan ook netjes opgepikt door HA:

https://esphome.io/components/mqtt.html

[martinvdm]

Yukkie schreef op donderdag 18 juli 2019 @ 08:13:
Home-Assistant 0.96 is uit: https://www.home-assistant.io/blog/2019/07/17/release-96/

Met zoals @Hmmbob hieronder terecht opmerkt een grote overhaul van het climat component. Wat mij vanmorgen opviel dat gebruikers van Opentherm_GW de config aan moeten passen: https://www.home-assistant.io/components/opentherm_gw/

Voorbeeld:

YAML:

Oud:
opentherm_gw:
  device: socket://1.0.0.1:6638
  climate:
    name: Thermostat
    precision: 0.5
    floor_temperature: true
  monitored_variables:
    - room_setpoint
    - room_temp
    - otgw_about

Nieuw:
opentherm_gw:
  thermostat:
    device: socket://1.0.0.1:6638
    name: "Thermostat"
    climate:
      precision: 0.5
      floor_temperature: true

Je er krijgt nu gratis en ongevraagd een hele bak sensors bij, die voor mij op dit moment overbodig zijn. Voor zover ik nu begrijp kun je niet zelf meer kiezen welke onderdelen je gemonitord wil hebben.

voorbeeld:
[Afbeelding: Openthem Gateway Sensoren]
(en dit is nog niet eens alles)

Ik ben er niet zo blij mee eigenlijk

Ik heb ook even in het begin het OpenthermGW component gebruikt in HA, maar merkte dat het, in ieder geval toen, niet stabiel was. Ik gebruik het al tijden via OTMonitor (docker) en dan vervolgens naar MQTT met een MQTT Climate. Dit werkt top. Wellicht is dat een optie.

[kmf]

Yoki1985 schreef op donderdag 18 juli 2019 @ 13:23:
[...]


esphome kan ook perfect overweg met MQTT. Deze worden dan ook netjes opgepikt door HA:

https://esphome.io/components/mqtt.html

Oh, dat is nieuw voor mij? Nieuwe feature? Ik had juist voor tasmota gekozen vanwege de GUI en MQTT. Maar goed, er is geen echte reden om voor het een of ander te kiezen denk ik.

[RobertMe]

kmf schreef op donderdag 18 juli 2019 @ 13:33:
[...]


Oh, dat is nieuw voor mij? Nieuwe feature? Ik had juist voor tasmota gekozen vanwege de GUI en MQTT. Maar goed, er is geen echte reden om voor het een of ander te kiezen denk ik.

ESPHome deed eerst juist alleen MQTT. Die directe HA integratie is pas relatief nieuwe (vanaf HA 0.90 of zo) en is voornamelijk gemaakt omdat het voor ESPHome beter/"compacter" is om op zo'n kleine microcontroller te draaien.

[Mars Warrior]

martinvdm schreef op donderdag 18 juli 2019 @ 13:31:
[...]
Ik heb ook even in het begin het OpenthermGW component gebruikt in HA, maar merkte dat het, in ieder geval toen, niet stabiel was. Ik gebruik het al tijden via OTMonitor (docker) en dan vervolgens naar MQTT met een MQTT Climate. Dit werkt top. Wellicht is dat een optie.

Zo heb ik het ook draaien (OTMonitor en MQTT Climate), en dat werkt al zo'n 1.5 jaar stabiel. Nooit geen problemen met updates van hass. En ik gebruik al die tijd ook meerdere MQTT Climate componenten omdat dat met MQTT gewoon standaard mogelijk is

Ik wacht maar weer ff op een .2 of .3 release voordat ik mijn docker omgeving weer een trap geef

[Frenck]

Mars Warrior schreef op donderdag 18 juli 2019 @ 13:46:
[...]

Ik wacht maar weer ff op een .2 of .3 release voordat ik mijn docker omgeving weer een trap geef

Als iedereen dat denkt, dan komen we nooit tot .2 of .3 en blijven we issues houden

Maar zonder gekheid, een run doen op de nieuwe versie met Docker om te zien of er issues zijn (and if so, deze reporten) is natuurlijk behulpzaam voor iedereen. Zeker met Docker kun je zo terug in case of issues.

[Yukkie]

@martinvdm @Mars Warrior Dat had ik in het verleden ook, toen het HA component nog nieuw en buggy was. Maar ik stoorde me aan het feit dat er 2 (in mijn ogen overbodige) stappen tussen zaten tussen mijn OTGW en HA. Sinds mijn overstap heeft het lange tijd stabiel gewerkt. Tot dus de grote overhaul van het climate component in HA 0.96.

Hoewel ik het wel een beetje slordig vind dat deze bug er nog in zit, ben ik het wel een beetje met Frenck eens. Als iedereen wacht tot een .2 of .3 versie dan zal de ontwikkeling van HA langzaam stil komen te liggen omdat er geen bugs gerapporteerd worden. En ach, de verwarming heb ik naar verwachting de komende dagen toch niet heel erg hard nodig

Edit:

Volgens mij heb ik het issue opgelost. Ik heb even de code van een ander climate component vergeleken en er miste een property in de climate.py van het opentherm_gw component. Als ik die property toevoeg bij mij, dan werkt het component weer. Heb het aan het issue toegevoegd, wellicht dat de developer er wat aan heeft om het op te lossen. Hij moet het nog wel even checken voor de zekerheid denk ik.

[ Voor 22% gewijzigd door Yukkie op 18-07-2019 15:53 ]

[Dw1-nl]

Om even hier in de discussie me te mengen nu het toch toevallig over verwarming gaat. Ik was van plan om bij mij thuis alles te digitaliseren kwa verwarming. Draai zigbee2mqtt en wilde overal op elke radiator een Eurotronic Spirit Zigbee wireless heater thermostat zetten. Deze dan met HA verbinden zodat ik per ruimte de verwarming open/dicht kan zetten. Moet dan wel iets hebben dat ik de ketel aan en uit kan zetten. Is daar OpenthermGW voor geschikt om tussen thermostaat en cv in te hangen? En hebben jullie die printplaat zelf gesoldeerd en op de pi aangesloten of via esp bordje erop of? Vind hier vrij weinig info over i.c.m. HA

[Vanx]

ANdrode schreef op woensdag 17 juli 2019 @ 22:41:
[...]


Is niet zo /heel/ betrouwbaar maar een leuke tool. Wanneer je SSL gebruikt zonder wildcard is crt.sh bijzonder effectief. Vrijwel 100% dekking voor de op dit moment geldige SSL certificaten.

offtopic:
Weet even niet wanneer de oudste certificaten zonder CT verlopen en of er nog CA's zijn die zonder issue-en

[...]


Wildcard certificate is de beste optie. Enumeratie voorkomen is in mijn ogen écht vaker een voordeel daarvan dan de flexibiliteit die het biedt.

Ha, cool, die werkt ook. Mijn link lijkt wat bronnen te combineren, maar zou die het ook direct van de SSL info halen? Ik weet 100% zeker dat mijn subdomein niet door google geindexed is.

Is er nog een andere manier om enumeratie van subdomeinen te doen?

[ANdrode]

Vanx schreef op donderdag 18 juli 2019 @ 15:59:
[...]
Ha, cool, die werkt ook. Mijn link lijkt wat bronnen te combineren, maar zou die het ook direct van de SSL info halen? Ik weet 100% zeker dat mijn subdomein niet door google geindexed is.

Doet hij niet. Voor mijn domein dat alleen op LAN bestaat (geen records in publieke DNS) heeft hij een domein niet waar wel een certificaat voor bestaan heeft.

Als ik dat deed dan zou ik dat wel doen. Certificate Transparency endpointen zijn te enumereren, dat is zelfs het idee.

Is er nog een andere manier om enumeratie van subdomeinen te doen?

Een (publieke) DNS server draaien en loggen. Of via een safe-browsing service. Die moet je beide dus vertrouwen met vrijwel jouw complete browser geschiedenis.

offtopic:
En natuurlijk de verplichte logging door ISP's

[Mars Warrior]

Frenck schreef op donderdag 18 juli 2019 @ 14:03:
[...]
Als iedereen dat denkt, dan komen we nooit tot .2 of .3 en blijven we issues houden

Maar zonder gekheid, een run doen op de nieuwe versie met Docker om te zien of er issues zijn (and if so, deze reporten) is natuurlijk behulpzaam voor iedereen. Zeker met Docker kun je zo terug in case of issues.

Dat klopt, en als de devs eens stoppen met die dwangneurose om dingen die perfect werkten te blijven veranderen, dan is het probleem ook opgelost: dan is het upgraden geen probleem.

Het grote probleem is ook dat ik af en toe MOET upgraden om een bug opgelost te krijgen, maar dat ik er weer één of meer niet werkende componenten voor terug krijg. Gratis en voor niks.

Het ontkopppelen via MQTT lost dat probleem op: daar bepaal ik zelf wat ik upgrade, en maak ik enkel gebruik van de hass MQTT functionaliteit. Vreemd genoeg krijgen de devs van die losse modules (containers) het wel voor elkaar om functies toe te voegen of uit te breiden zonder breaking changes.

Ik hoop dan ook dat je straks in hass de plugins en hun versie kunt kiezen (net als bij Docker), zodat je zelf kunt bepalen wat je upgrade of niet. Want ook dan zal dit probleem min of meer verdwijnen.

Yukkie schreef op donderdag 18 juli 2019 @ 14:28:
@martinvdm @Mars Warrior Dat had ik in het verleden ook, toen het HA component nog nieuw en buggy was. Maar ik stoorde me aan het feit dat er 2 (in mijn ogen overbodige) stappen tussen zaten tussen mijn OTGW en HA. Sinds mijn overstap heeft het lange tijd stabiel gewerkt. Tot dus de grote overhaul van het climate component in HA 0.96.

Hoewel ik het wel een beetje slordig vind dat deze bug er nog in zit, ben ik het wel een beetje met Frenck eens. Als iedereen wacht tot een .2 of .3 versie dan zal de ontwikkeling van HA langzaam stil komen te liggen omdat er geen bugs gerapporteerd worden. En ach, de verwarming heb ik naar verwachting de komende dagen toch niet heel erg hard nodig

Ik heb via OTMonitor zowel MQTT als de relay naar de OTGW component binnen hass draaien. Daaraan kan ik zien dat MQTT het altijd doet, en dat de OTGW component behoorlijk onbetrouwbaar is na bijv. een herstart of upgrade van hass. Mijn log loopt dan vol met foutmeldingen en ik kan mijn kachel dan niet meer bedienen.

Dit is dan de meest irritante (die ook nu weer vanaf 17 juli in mijn log staat...)

code:

Could not connect to serial device on socket://192.168.2.202:7686. Will keep trying. Reported error was: Could not open port socket://192.168.2.202:7686: timed out

Naast bergen met foutmeldingen als "Command PS failed", "Command PR failed", "Unknown message in command queue: PR, en nog wat in die richting

Neemt niet weg dat ik benieuwd ben hoe hass naar een versie 1.0 gaat en de gebruikersvriendelijkheid op zo'n niveau is dat de gemiddelde gebruiker hass omarmt. Maar dan moet men dus wel subiet stoppen met breaking changes, want dat gaat de gemiddelde gebruiker toch snel irriteren als plotseling het licht, de kachel en andere dingen het weer niet doen

[martinvdm]

Tja ik ben ik ook altijd wel terughoudend maar wel eens met @Frenck . Gebruik zelf docker en zeker op docker is het peanuts om een oudere versie terug te gaan, of een aparte dev omgeving op te zetten. Een bijdrage tot oplossing van problemen zal iedereen vervolgens helpen.

[Yukkie]

@Mars Warrior Zou die timeout error niet veroorzaakt kunnen worden doordat je otmonitor én het otgw component gebruikt? Ik herken die fouten namelijk totaal niet (meer). Ik had zoiets ook toen ik beide had draaien, maar nu al lange tijd niet meer.

[mAiden88]

@martinvdm ,

Gisteren was de proef of jou scriptje zou werken ivm de afvalbakken, helaas gaat dat niet helemaal goed.
Ik ben er wel achter waarom niet, maar hoe dat nu precies ga doen, is nog niet helemaal duidelijk.
Ik roep het om 21uur op sun of woensdag aan (Bakken worden of op maandag of op donderdag geleegd hier.)
Dan staat er bij de desbetreffende afvalbak in HA "2uur".
Hoe laat ik hem kijken naar de bak waar nog 2uur staan?

code:

           {% if as_timestamp(states.sensor.twente_milieu_gft.state) | timestamp_custom('%Y%m%d') == now().strftime("%Y%m%d")  %}
           Zet jij de groene otto zo even aan straat?
           {% elif as_timestamp(states.sensor.twente_milieu_plastic_en_verpakking.state) | timestamp_custom('%Y%m%d') == now().strftime("%Y%m%d") %}
           Zet jij de oranje otto zo even aan straat?
           {% elif as_timestamp(states.sensor.twente_milieu_restafval.state) | timestamp_custom('%Y%m%d') == now().strftime("%Y%m%d") %}
           Zet jij de grijze otto zo even aan straat?
           {% elif as_timestamp(states.sensor.twente_milieu_papier.state) | timestamp_custom('%Y%m%d') == now().strftime("%Y%m%d") %}
           Zet jij de blauwe otto zo even aan straat?
           {% else %}
           Vandaag geen Otto's aan de weg!

[Lifelogger]

Frenck schreef op donderdag 18 juli 2019 @ 11:48:
@sopi De climate basis van HA in 0.96 is compleet herschreven. Alle climate integraties zijn hierop aangepast. In het geval van rooted Toon, gaat het om een custom component. De betreffende auteur zal dus zijn custom integratie moeten updaten.

Ik wacht nog even met upgraden dan. Wel jammer, kijk erg uit naar de nieuwe features. :-)

[Kenhas]

Zou iemand me kunnen helpen met de instellen van mijn nieuwe Aeon Doorbell 6 (KLIK)?

Als ik dan bij Instellingen - Z-wave - Node Config kijk, zie ik dit (klein screenshot maar er zijn een 30-35 nodes)


Volgens opzoekingen zou ik parameter 37 moeten aanpassen om het volume te regelen. Dat staat nu echt veel maar dan ook veel te luid. Maar geen parameter 37 te vinden.

Als ik bijvoorbeeld 3 selecteer, moet ik een integer tussen 2147483648 en 2147483647 ingeven. Maar ik weet niet waar ik die integer vandaan moet halen. De standaard waarde die ingevuld is, is 33554433 dus dat klopt ook al niet met de minimum/maximum waarden
In Hassio wordt er wel verwezen naar de Engineering Specification van de deurbel. Dit is HIER te vinden.
Maar het lichtje begint niet te branden bij mij. Ik zie het gewoon niet.

[sopi]

Lifelogger schreef op donderdag 18 juli 2019 @ 18:55:
[...]


Ik wacht nog even met upgraden dan. Wel jammer, kijk erg uit naar de nieuwe features. :-)

Heb zelf nog wel even gekeken naar climate.py en dat vergeleken met de pull request
( https://github.com/home-assistant/home-assistant/pull/23899 ), zie redelijk wat zaken die aangepast moeten worden maar mijn kennis gaat nog niet zover dus ik waag me er niet aan.

Afwachten dus maar, 0.96 is wel weer een mooie stap vooruit kan ik je vertellen, maar voor nu maar even terug 0.95.4 want anders raken mijn automations over de zeik.

[Lifelogger]

sopi schreef op donderdag 18 juli 2019 @ 19:59:
[...]


Heb zelf nog wel even gekeken naar climate.py en dat vergeleken met de pull request
( https://github.com/home-assistant/home-assistant/pull/23899 ), zie redelijk wat zaken die aangepast moeten worden maar mijn kennis gaat nog niet zover dus ik waag me er niet aan.

Afwachten dus maar, 0.96 is wel weer een mooie stap vooruit kan ik je vertellen, maar voor nu maar even terug 0.95.4 want anders raken mijn automations over de zeik.

Ja, veel mooie dingen ook gezien in 0.96. Maar kan niet zonder gebruik van m'n Toon. Hoop dat de maker van het script het snel bijwerkt.

[stijn1309]

Een update vanuit mijn kant.

De shelly 2.5 geïnstalleerd en het werkt. Kan de garagedeur nu via de app bedienen.
Volgende stap is om deze aan HA te knopen, installatie is bezig voor mij PI.

Maar wat een prutswerk van diegene die de deur heeft opgehangen... ze hebben er dus een relais tussen gezet, omdat ze het juiste materiaal niet hadden waarschijnlijk. Nu kan ik dus de deur alleen bedienen via de app. Morgen langs de bouwmarkt om ervoor te zorgen dat het dan ook weer werkt via de knop en buiten met de sleutel.

[Frenck]

Mars Warrior schreef op donderdag 18 juli 2019 @ 17:53:
[...]

Dat klopt, en als de devs eens stoppen met die dwangneurose om dingen die perfect werkten te blijven veranderen, dan is het probleem ook opgelost: dan is het upgraden geen probleem.

Daarbij kijk je (denk ik) hoofdzakelijk naar je eigen systeem, die ogenschijnlijk perfect werkt. De realiteit is echter anders als je kijkt naar al onze gebruikers. De reden achter deze grote climate breaking change is breed uitgemeten op onze dev blog:

https://developers.home-a...7/03/climate-cleanup.html

Als je na het lezen van die blog nog steeds vindt dat deze change niet nodig was... tja... dan weet ik het ook niet meer.

De reden achter al deze breaking changes op dit moment, is met name het klaarstomen voor een solidere basis voor de toekomst en HA daadwerkelijk naar stable te krijgen. We hebben 1.0 immers nog niet bereikt. Het pad er naar toe is overigens helder en uitgewerkt.

Neemt niet weg, dat het waarschijnlijk nooit 100% zal verdwijnen. Home Assistant is immers een bridge tussen verschillende protocollen en API's van fabrikanten. Ook deze wijzigen constant allerlei zaken, geen excuus, wel een feit.

Waarom mijn reactie? Ik ben een van de devs waar je aan refereerd.

[ Voor 9% gewijzigd door Frenck op 18-07-2019 22:41 ]

[Lifelogger]

Frenck schreef op donderdag 18 juli 2019 @ 22:39:
[...]


Daarbij kijk je (denk ik) hoofdzakelijk naar je eigen systeem, die ogenschijnlijk perfect werkt. De realiteit is echter anders als je kijkt naar al onze gebruikers. De reden achter deze grote climate breaking change is breed uitgemeten op onze dev blog:

https://developers.home-a...7/03/climate-cleanup.html

Als je na het lezen van die blog nog steeds vindt dat deze change niet nodig was... tja... dan weet ik het ook niet meer.

De reden achter al deze breaking changes op dit moment, is met name het klaarstomen voor een solidere basis voor de toekomst en HA daadwerkelijk naar stable te krijgen. We hebben 1.0 immers nog niet bereikt. Het pad er naar toe is overigens helder en uitgewerkt.

Neemt niet weg, dat het waarschijnlijk nooit 100% zal verdwijnen. Home Assistant is immers een bridge tussen verschillende protocollen en API's van fabrikanten. Ook deze wijzigen constant allerlei zaken, geen excuus, wel een feit.

Waarom mijn reactie? Ik ben een van de devs waar je aan refereerd.

Prima verwoord! Niets dan bewondering voor wat jullie doen. HA is echt geweldig. Zeker als je van Domoticz af komt!

[Yelti]

Ik zou denken dat je de binnenste en buitenste knop parallel schakelt op de inputs van je Shelly.
Zo behoudt je de bestaande functionaliteit en krijg je de app erbij.

stijn1309 schreef op donderdag 18 juli 2019 @ 21:00:
Een update vanuit mijn kant.

De shelly 2.5 geïnstalleerd en het werkt. Kan de garagedeur nu via de app bedienen.
Volgende stap is om deze aan HA te knopen, installatie is bezig voor mij PI.

Maar wat een prutswerk van diegene die de deur heeft opgehangen... ze hebben er dus een relais tussen gezet, omdat ze het juiste materiaal niet hadden waarschijnlijk. Nu kan ik dus de deur alleen bedienen via de app. Morgen langs de bouwmarkt om ervoor te zorgen dat het dan ook weer werkt via de knop en buiten met de sleutel.

[Imperial Guard]

martinvdm schreef op donderdag 18 juli 2019 @ 18:12:
Tja ik ben ik ook altijd wel terughoudend maar wel eens met @Frenck . Gebruik zelf docker en zeker op docker is het peanuts om een oudere versie terug te gaan, of een aparte dev omgeving op te zetten. Een bijdrage tot oplossing van problemen zal iedereen vervolgens helpen.

Wat is het meest handige om Home Assistant in een dev omgeving te laten draaien?

[lubbertkramer]

Imperial Guard schreef op vrijdag 19 juli 2019 @ 08:38:
[...]


Wat is het meest handige om Home Assistant in een dev omgeving te laten draaien?

Ik haal mijn docker container tijdelijk even offline en draai dan een dev container op dezelfde map (maar zonder influx/sql connectie) om te testen of er grote dingen omvallen. Hierdoor heb ik wel mijn omgeving i.p.v. een echte (lege) dev omgeving.

Mars Warrior schreef op donderdag 18 juli 2019 @ 17:53:
Dat klopt, en als de devs eens stoppen met die dwangneurose om dingen die perfect werkten te blijven veranderen, dan is het probleem ook opgelost: dan is het upgraden geen probleem.

Het grote probleem is ook dat ik af en toe MOET upgraden om een bug opgelost te krijgen, maar dat ik er weer één of meer niet werkende componenten voor terug krijg. Gratis en voor niks.

Waarom ga je dan niet alles in docker draaien en heb je alles in eigen beheer i.p.v. via Hass plugins. Hierdoor ben je dus ook zelf in control over de versie i.p.v. een update knop die naar de nieuwste versie gaat. Hier ook gestart met Hass maar toch over naar HA in docker en alles nu apart in een eigen docker. Dit maakt het beheren/loskoppelen van zaken die aan HA hangen makkelijker en minder afhankelijk. Probleem ligt daarom niet echt bij de dev's omdat die genoeg mogelijkheden geven hoe je HA kunt draaien maar meer hoe jij je omgeving hebt ingericht

[ Voor 66% gewijzigd door lubbertkramer op 19-07-2019 09:36 ]

[redah]

Ik heb een simpele automation om onze Google speaker een melding te geven als de wasmachine (op zolder) klaar is:

code:

- id: wasmachine_klaar
  alias: Wasmachine is klaar
  trigger:
  - platform: numeric_state
    entity_id: sensor.smart_plug_zolder_watts
    below: 1.0
    for:
      minutes: 1
  action:
  - service: tts.google_say
    data_template:
      volume_level: 0.5
      message: De wasmachine is klaar
      entity_id: media_player.google_mini_woonkamer
      language: nl
      cache: false

Ofwel, zodra het wattage onder de 1 watt zakt, komt er een melding. Echter geeft de plug regelmatig ook 'unknown' als state aan. En zodra de state dan weer naar '0' springt vindt HA het een goed idee om de Google speaker te laten praten Ik heb even zitten klooien maar kom er niet uit om te zorgen dat 'unknown' genegeerd wordt.

Ik dacht dat het wellicht handig was om een 'from:' 'to:' te gebruiken, zodat de automation alleen maar triggert als er van >1 naar <1 gegaan wordt, maar krijg dat niet voor elkaar in YAML.

Heeft iemand een suggestie?

[Hmmbob]

Er zit een opentherm fix in 0.96.1:
Release 0.96.1 - July 18

• Show off value (@pvizeli - #25236)
• Fix eq3btsmart (@pvizeli - #25238) (eq3btsmart docs)
• Make presets prettier (@cgtobi - #25245) (netatmo docs)
• Fix the unit of measurement for ecobee climate (@cgtobi - #25246) (ecobee docs)
• ecobee Preset Fix (@geekofweek - #25256) (ecobee docs)
• Update CT80 Humidity call (@zombielinux - #25258) (radiotherm docs)
• Restore SmartThings A/C on/off services (@andrewsayre - #25259) (smartthings docs)
• Add hvac modes back to opentherm (@balloob - #25268) (opentherm_gw docs)
• Added states and modes for zwave climate (@stboch - #25274) (zwave docs)

[JBS]

lubbertkramer schreef op vrijdag 19 juli 2019 @ 09:32:
[...]


Waarom ga je dan niet alles in docker draaien en heb je alles in eigen beheer i.p.v. via Hass plugins. Hierdoor ben je dus ook zelf in control over de versie i.p.v. een update knop die naar de nieuwste versie gaat. Hier ook gestart met Hass maar toch over naar HA in docker en alles nu apart in een eigen docker. Dit maakt het beheren/loskoppelen van zaken die aan HA hangen makkelijker en minder afhankelijk. Probleem ligt daarom niet echt bij de dev's omdat die genoeg mogelijkheden geven hoe je HA kunt draaien maar meer hoe jij je omgeving hebt ingericht

Zelf gebruik ik ook nog steeds Hass.io met een aantal add-ons. Voornaamste reden om (nog) niet over te stappen is het gemak dat je met de add-ons hebt: Ingress en naadloze integratie van (in mijn geval) ESPHome, Log Viewer, Mosquitto roker en Visual Studio Code. Tuurlijk kan dat allemaal in losse dockers, maar dat betekent wel meer configuratie om dit alles net zo eenvoudig te kunnen benaderen, inrichten en gebruiken zoals nu.
Voordeel van docker versie kiezen weegt (voor mij) nu nog niet op tegen de tijd die de overstap zal kosten.

[lubbertkramer]

JBS schreef op vrijdag 19 juli 2019 @ 09:43:
[...]
Zelf gebruik ik ook nog steeds Hass.io met een aantal add-ons. Voornaamste reden om (nog) niet over te stappen is het gemak dat je met de add-ons hebt: Ingress en naadloze integratie van (in mijn geval) ESPHome, Log Viewer, Mosquitto roker en Visual Studio Code. Tuurlijk kan dat allemaal in losse dockers, maar dat betekent wel meer configuratie om dit alles net zo eenvoudig te kunnen benaderen, inrichten en gebruiken zoals nu.
Voordeel van docker versie kiezen weegt (voor mij) nu nog niet op tegen de tijd die de overstap zal kosten.

Het blijft een ieder zijn keuze wat hij/zij draait, maar als je zoals tweaker hierboven volledig in control wilt zijn is docker beter dan Hass + plugins waar je geen versie kunt kiezen maar alleen kunt updaten naar de nieuwste versie. In die context staat de reactie ook geschreven, niet in wat beter/slechter is

Wil wel nuance aanbrengen aan de uitspraak dat je meer configuratie nodig hebt, dit is namelijk niet geheel waar. Bijvoorbeeld ESPhome / Deconz / MQTT is net als de plugin installeren en via de instellingen pagina integraties de koppeling maken en niet meer naar omkijken.

[mAiden88]

redah schreef op vrijdag 19 juli 2019 @ 09:37:
Ik heb een simpele automation om onze Google speaker een melding te geven als de wasmachine (op zolder) klaar is:

@redah

code:

- id: wasmachine_klaar
  alias: Wasmachine is klaar
  trigger:
  - platform: numeric_state
    entity_id: sensor.smart_plug_zolder_watts
    below: 1.0
    for:
      minutes: 1
  action:
  - service: tts.google_say
    data_template:
      volume_level: 0.5
      message: De wasmachine is klaar
      entity_id: media_player.google_mini_woonkamer
      language: nl
      cache: false

Ofwel, zodra het wattage onder de 1 watt zakt, komt er een melding. Echter geeft de plug regelmatig ook 'unknown' als state aan. En zodra de state dan weer naar '0' springt vindt HA het een goed idee om de Google speaker te laten praten Ik heb even zitten klooien maar kom er niet uit om te zorgen dat 'unknown' genegeerd wordt.

Ik dacht dat het wellicht handig was om een 'from:' 'to:' te gebruiken, zodat de automation alleen maar triggert als er van >1 naar <1 gegaan wordt, maar krijg dat niet voor elkaar in YAML.

Heeft iemand een suggestie?

Als ik me niet vergis, dien de trigger zo opgebouwd te worden:

code:

trigger:
  platform: numeric_state
  entity_id: sensor.name_power
  value_template: '{{ states.sensor.name_power.state }}'
  below: 1000
  for:
    seconds: 10

[JBS]

lubbertkramer schreef op vrijdag 19 juli 2019 @ 09:56:
[...]


Het blijft een ieder zijn keuze wat hij/zij draait, maar als je zoals tweaker hierboven volledig in control wilt zijn is docker beter dan Hass + plugins waar je geen versie kunt kiezen maar alleen kunt updaten naar de nieuwste versie. In die context staat de reactie ook geschreven, niet in wat beter/slechter is

Wil wel nuance aanbrengen aan de uitspraak dat je meer configuratie nodig hebt, dit is namelijk niet geheel waar. Bijvoorbeeld ESPhome / Deconz / MQTT is net als de plugin installeren en via de instellingen pagina integraties de koppeling maken en niet meer naar omkijken.

Eens. Als je argument 'in control zijn' is, dan is de docker benadering inderdaad absoluut de juiste weg. Mijn allerbelangrijkste container (deCONZ) draait dan ook niet als add-on, juist om die reden.

En klopt, enkel het koppelen van losse docker containers via Integraties is geen extra hobbel. Waar ik meer werk in zie zitten is het koppelen van bijvoorbeeld Log Viewer (wat overigens tegenwoordig ook prima mogelijk is zoals je al eerder eens poste), user management voor Mosquitto broker (gekozen voor device een eigen inlog, wellicht niet per se nodig) en het (vanuit HA) benaderen van de verschillende interfaces (wat overigens door Traefik ook zo geregeld zal zijn).

Maar iedereen 'n eigen keuzes, de afweging gemak vs in control is per add-on/container voor mij anders, vandaar voorlopig nog even Hass.io

[Yukkie]

redah schreef op vrijdag 19 juli 2019 @ 09:37:
Ik heb een simpele automation om onze Google speaker een melding te geven als de wasmachine (op zolder) klaar is:

code:

- id: wasmachine_klaar
  alias: Wasmachine is klaar
  trigger:
  - platform: numeric_state
    entity_id: sensor.smart_plug_zolder_watts
    below: 1.0
    for:
      minutes: 1
  action:
  - service: tts.google_say
    data_template:
      volume_level: 0.5
      message: De wasmachine is klaar
      entity_id: media_player.google_mini_woonkamer
      language: nl
      cache: false

Ofwel, zodra het wattage onder de 1 watt zakt, komt er een melding. Echter geeft de plug regelmatig ook 'unknown' als state aan. En zodra de state dan weer naar '0' springt vindt HA het een goed idee om de Google speaker te laten praten Ik heb even zitten klooien maar kom er niet uit om te zorgen dat 'unknown' genegeerd wordt.

Ik dacht dat het wellicht handig was om een 'from:' 'to:' te gebruiken, zodat de automation alleen maar triggert als er van >1 naar <1 gegaan wordt, maar krijg dat niet voor elkaar in YAML.

Heeft iemand een suggestie?

Kun je de plug ook aan en uit zetten? Ik heb mijn automation code van het HA forum afgeplukt, die zet de plug/wasmachine na 5 minuten ook helemaal uit. Ik krijg (denk ik) daardoor ook nooit false positives.

[ Voor 4% gewijzigd door Yukkie op 19-07-2019 11:07 ]

[Dw1-nl]

Yukkie schreef op vrijdag 19 juli 2019 @ 11:06:
[...]


Kun je de plug ook aan en uit zetten? Ik heb mijn automation code van het HA forum afgeplukt, die zet de plug/wasmachine na 5 minuten ook helemaal uit. Ik krijg (denk ik) daardoor ook nooit false positives.

En als je de wasmachine dan weer wilt aanzetten moet je eerst de plug aanzetten? Ben toevallig nu net bezig met een Sonoff POW R2 had er eerst tasmota op staan en nu esphome aan de hand van deze video zo geflashed dat de sonoff naar HA terugkoppelt of de wasmachine aan of uit staat ivm dit in HA bepalen. YouTube: Sonoff & ESPHome?

YAML:

- id: '1563527969545'
  alias: Nieuwe automatisering
  trigger:
  - entity_id: binary_sensor.washing_machine_running
    from: 'on'
    platform: state
    to: 'off'
  condition: []
  action:
  - data:
      entity_id: media_player.woonkamer_2
      message: De wasmachine is klaar!
    service: tts.google_say

[ Voor 17% gewijzigd door Dw1-nl op 19-07-2019 11:23 ]

[Yukkie]

@Dw1-nl yup, precies. De plug zit bij mij binnen handbereik, dus dat is voor mij geen issue. Anders zou je hem via de app weer aan kunnen zetten.

[trekker22]

iemand een idee of die Intel NUC image voor Hass.io ook nog werkt op een oude Asrock ION152D (Atom D525 intel CPU) of moet het echt een NUC zijn?

[gwystyl]

Pfff ik ben maar weer eens vanaf 0 begonnen. Ik had een auto-update taak gevonden die ik in mijn Synology kon toevoegen, maar daarbij heb ik waarschijnlijk niet alle dingen aangepast naar mijn situatie waardoor ik na die update-taak met een niet werkende HA zat.
Ik heb nu de docker-installatie voor Synology weer uitgevoerd en ga nou kijken hoe ik delen van mijn config-bestanden weer kan gebruiken.

Ik heb tot nu toe nog een super simpele setup waarbij ik eigenlijk alleen het weer en de nmapdevicescanner gebruik om te kijken wie er thuis zijn, en dit weergegeven in verschillende tabbladen.
Afgelopen week ben ik aan het klooien geweest met het toevoegen van een nieuwe tablet, maar ik blijf vastlopen op de combinatie naamgeving van entiteit, friendly name en tracking.
Voor zover ik het begrijp is dit ongeveer de simpelste setup die je kan hebben, maar het houdt me wel tegen om alles te automatiseren. Ik heb nog een paar Sonoff switches liggen die ik wilde toevoegen, maar ik vrees dat dat voor mij aardig lastig gaat worden, en als het niet werkt heb ik vrouwlief over de zeik als ineens bepaalde lampen niet meer werken.

[redah]

mAiden88 schreef op vrijdag 19 juli 2019 @ 10:00:

Als ik me niet vergis, dien de trigger zo opgebouwd te worden:

code:

trigger:
  platform: numeric_state
  entity_id: sensor.name_power
  value_template: '{{ states.sensor.name_power.state }}'
  below: 1000
  for:
    seconds: 10

Ik heb geen idee of dat moet (mijn huidige versie werkt) maar als ik zo even kijk lost dat het probleem niet op, toch? Deze zal nog steeds triggeren als de state van 'unknown' naar '0' gaat (want '0' is onder '1000').

Yukkie schreef op vrijdag 19 juli 2019 @ 11:06:

Kun je de plug ook aan en uit zetten? Ik heb mijn automation code van het HA forum afgeplukt, die zet de plug/wasmachine na 5 minuten ook helemaal uit. Ik krijg (denk ik) daardoor ook nooit false positives.

Dat kan, maar dan is de WAF direct weg. Als de wasmachine aan wordt gezet, en hij niks doet omdat ze de plug is vergeten aan te zetten (en dat gaat meerdere keren gebeuren) dan is het snel gedaan met domotica

Bovendien, automation moet er juist voor zorgen dat je geen manuele handelingen meer hoeft te doen...

[Mars Warrior]

Frenck schreef op donderdag 18 juli 2019 @ 22:39:
[...]
Daarbij kijk je (denk ik) hoofdzakelijk naar je eigen systeem, die ogenschijnlijk perfect werkt. De realiteit is echter anders als je kijkt naar al onze gebruikers.

Ik beheer(de) 5 Home Assistant installaties, en geen van allen werken perfect: ze hebben allemaal problemen met de geïntegreerde componenten die kleine tot grote problemen vertonen. Sommige zonder gevolgen voor de eindgebruiker, en andere die behoorlijk irritant zijn voor de eindgebruiker.

Toch willen ze allemaal hass blijven gebruiken

De reden achter deze grote climate breaking change is breed uitgemeten op onze dev blog:
https://developers.home-a...7/03/climate-cleanup.html

Als je na het lezen van die blog nog steeds vindt dat deze change niet nodig was... tja... dan weet ik het ook niet meer.

Ik heb werkelijk niks tegen refactoring zoals netjes in het blog staat aangegeven: dat heeft een belangrijk doel om dingen eenvoudiger te maken voor het beheer en de ontwikkelaars.
Echter als je elke 2 weken dit soort breaking changes hebt, dan is er naar mijn mening en ervaring iets mis met de opzet (architectuur) van het geheel, zeker als elke technische wijziging doorkomt bij de eindgebruiker.

Zoals ik in het architectuur issue (https://github.com/home-assistant/architecture/issues/192) al eerder heb aangegeven zijn er zat mogelijkheden - hass toont dat aan namelijk - om met veel minder impact en werk voor de devs de software te ontwikkelen en stabiel te krijgen met zo min mogelijk overlast voor de eindgebruiker.

Ook de community laat recent met HACS zien dat het allemaal ook veel eenvoudiger en overzichtelijker kan om plugins en updates te kiezen en te installeren.

Door de enorme hoeveelheid werk om elke 2 weken de problemen met 5 hass installaties op te lossen, gecombineerd met de kennis en ervaring uit mijn dagelijks werk (architect / manager van complexe IoT systemen) ben ik op een gegeven moment mijn energie gaan steken in een opzet die het onderhoudswerk drastisch omlaag brengt: het gebruiken van plugins die gekoppeld zijn via MQTT én perfect via MQTT discovery integreren met hass:

• Alle op ESP* gebaseerde systemen (Tasmota, ESPHome via MQTT, etc.)
• otgw2mqtt, koppelen van Opentherm kachels (meervoud) aan hass.
• Zigbee2mqtt, waar ik veel heb lopen testen voor de hass integratie
• DSMR Reader, waar ik in 2016 al (2017 gerealiseerd) een issue voor MQTT integratie heb ingediend
• zwave2mqtt, waar ik na grote problemen met de hass zwave component ook maar een issue voor MQTT/ hass integratie heb ingediend en die nu in beta is.

Het kenmerk van al deze modules of hoe je ze ook noemen wilt is dat ze:

• Sterk in ontwikkeling zijn, dus veel wijzigingen hebben, net als hass
• Ze hebben het afgelopen jaar (voor zover ze er toen al waren) icm hass op alle 5 de installaties geen problemen veroorzaakt: ze doen het gewoon altijd vanwege de standaard koppeling en integratie met hass over MQTT. Refactoring zonder gevolgen voor de buitenkant en gebruik.
• Ik zonder problemen ook meerdere instanties kan koppelen itt de geïntegreerde hass componenten. Dus je vakantiehuisje in Spanje (Zigbee en Wifi) is gewoon te zien in hass
• Ik zelf kan mixen en matchen qua versie: ik kies gewoon het juiste label/versie voor de Docker container en ram op de deploy knop in Portainer. Problemen? Dan weer ff terug en alles werkt weer.

Ik ben een grote fan van hass en steek dus eigenlijk heel wat tijd en energie in hass, maar dan via de MQTT route. Ik heb factoren minder werk bij elke update van hass (en wacht daarom maar tot een .3 of .4 versie om dat werk nog verder te reduceren) en steek mijn tijd liever in het maken van een mooie Lovelace interface, automations en het uitproberen van custom components die ik simpel installeer via HACS

[tomdh76]

Ik probeer twee home assistants aan elkaar te koppelen via MQTT maar loop tegen probleem aan dat alle sensoren etc worden ingelezen wat weer leidt tot crashen. Ik hoef ook eigenlijk maar 1 sensor te transporteren van master HA naar slave HA. Ik wil namelijk als ik mijn alarm aanzet (sensor op master) de tuinverlichting uitzetten (gekoppeld via slave HA). Mijn broker staat op een synology en daar komt alles van de master.
Kan iemand me helpen?

Het begint al met de vraag of ik MQTT statestream of eventstream moet gebruiken op de master. (ik denk statestream) https://www.home-assistant.io/components/mqtt_statestream/

Ik zou graag maar 1 sensor dus willen doorsturen maar include werkt niet (alles wordt nog gepublished)

In de slave dan een sensor maken die reageert op de subscribed topic?

https://www.home-assistant.io/components/sensor.mqtt/

[MyBearTibbers]

Ik ben onlangs overgestapt van Domoticz naar HA. HASSOS op een Pi gezet en na een weekendje beunen de basis werkend gekregen.
Nu wil ik de installatie gaan overzetten naar mijn docker server. Echter, zijn hier veel verschillende wellus-nietus topics over te vinden en ik ben de draad een beetje kwijt.
Mijn vraag is, is het mogelijk HA in een docker container te stoppen, mijn complete configuratie kopiëren plakken? En is de addon-store op deze manier ook nog steeds te gebruiken?

[LigeTRy]

MyBearTibbers schreef op vrijdag 19 juli 2019 @ 12:54:
Ik ben onlangs overgestapt van Domoticz naar HA. HASSOS op een Pi gezet en na een weekendje beunen de basis werkend gekregen.
Nu wil ik de installatie gaan overzetten naar mijn docker server. Echter, zijn hier veel verschillende wellus-nietus topics over te vinden en ik ben de draad een beetje kwijt.
Mijn vraag is, is het mogelijk HA in een docker container te stoppen, mijn complete configuratie kopiëren plakken? En is de addon-store op deze manier ook nog steeds te gebruiken?

Het is inderdaad even puzzelen maar ik heb hass.io (dus met addon store) in docker draaien. Let op dat dit best wel fragiel kan zijn (elke addon wordt een eigen container, en hassio heeft een eigen supervisor)

https://www.smarthomebegi...x/#Setup_HASSio_on_Docker

Volgens mij heb ik deze guide gebruikt (check vooral de github goed). succes ermee!

[Yukkie]

redah schreef op vrijdag 19 juli 2019 @ 11:57:


Dat kan, maar dan is de WAF direct weg. Als de wasmachine aan wordt gezet, en hij niks doet omdat ze de plug is vergeten aan te zetten (en dat gaat meerdere keren gebeuren) dan is het snel gedaan met domotica

Bovendien, automation moet er juist voor zorgen dat je geen manuele handelingen meer hoeft te doen...

Snap ik, maar daar heb ik gelukkig(?) geen last van vooralsnog. Eigenlijk zou je moeten proberen achterhalen wat die NULL values veroorzaakt en dat proberen op te lossen. Dat lijkt mij de basis van je probleem. Wat je ook doet met een automation om er omheen te werken, het zal altijd sub optimaal zijn denk ik

[MyBearTibbers]

wessel145 schreef op vrijdag 19 juli 2019 @ 13:20:

Super, dankjewel! Ga het eens proberen.
Fragiel maakt me niet zo uit, mocht de boel crashen heb ik het op deze manier ook binnen no-time weer draaien via de Pi

[stijn1309]

Ik doe vast iets heel basics fout.. maar ik kom er maar niet achter.

1. Ik heb Home Assistant geïnstalleerd op mijn PI.
2. Toen heb ik de Mosquitto MQTT add-in geïnstalleerd.
3. Account aangemaakt om devices te koppelen.
4. Shelly MQTT geactiveerd en daar het ip-adres ingevuld van de PI met poort 1883
5. In de configuration het volgende ingevuld (had eerst meer maar deze basis doet ook niets):

code:

switch:
  - platform: mqtt
    name: "Garagedeur"
    command_topic: "shellies/shellyswitch25-74516A/relay/0/command"

Er gebeurt gewoon niets heb het ook al geprobeerd met /relay/1 maar zelfde resultaat.

Ergens moet ik iets gemist hebben... maar ik kan het niet vinden.

[Slaut]

stijn1309 schreef op vrijdag 19 juli 2019 @ 15:10:
Ik doe vast iets heel basics fout.. maar ik kom er maar niet achter.

1. Ik heb Home Assistant geïnstalleerd op mijn PI.
2. Toen heb ik de Mosquitto MQTT add-in geïnstalleerd.
3. Account aangemaakt om devices te koppelen.
4. Shelly MQTT geactiveerd en daar het ip-adres ingevuld van de PI met poort 1883
5. In de configuration het volgende ingevuld (had eerst meer maar deze basis doet ook niets):

code:

switch:
  - platform: mqtt
    name: "Garagedeur"
    command_topic: "shellies/shellyswitch25-74516A/relay/0/command"

Er gebeurt gewoon niets heb het ook al geprobeerd met /relay/1 maar zelfde resultaat.

Ergens moet ik iets gemist hebben... maar ik kan het niet vinden.

Als de Shelly en Mosquitto in hetzelfde netwerk zitten, zal het probleem of bij de Shelly liggen, of Mosquitto. Heb je andere MQTT devices die wel werken? Welke firmware staat op de Shelly, is dat de originele, Tasmota, ESPeasy of iets anders?

[JBS]

@stijn1309 Probeer eens te verbinden op de poort die je onder 'Host' hebt ingevuld?

[stijn1309]

Slaut schreef op vrijdag 19 juli 2019 @ 15:16:
[...]


Als de Shelly en Mosquitto in hetzelfde netwerk zitten, zal het probleem of bij de Shelly liggen, of Mosquitto. Heb je andere MQTT devices die wel werken? Welke firmware staat op de Shelly, is dat de originele, Tasmota, ESPeasy of iets anders?

Is mijn eerste en enige MQTT device tot nu toe. Orginele firmware van Shelly. Ik vermoed dat het in mijn installatie van de broker zit. Beide zitten in hetzelfde netwerk!

Ik heb alleen de Add-on geïnstalleerd en daarna niets in de config aangepast/gezet het zou vanzelf moeten werken...

hier de config van de Mosquitto add-on

code:

{
  "logins": [],
  "anonymous": false,
  "customize": {
    "active": false,
    "folder": "mosquitto"
  },
  "certfile": "fullchain.pem",
  "keyfile": "privkey.pem"
}

@JBS Hoe bedoel je te verbinden met de poort die je het ingevuld onder host?

[JBS]

@stijn1309 Wanneer je de add-on pagina opent en wat naar beneden scrollt, zie je op 'n gegeven moment onder het 'Config' gedeelte het kopje 'Network' met daaronder hetgeen uit mijn screenshot.

Probeer eens vanaf de Shelly te verbinden op de poort die onder 'Host' achter 8686 staat.

[ Voor 26% gewijzigd door JBS op 19-07-2019 15:28 ]

[stijn1309]

JBS schreef op vrijdag 19 juli 2019 @ 15:23:
@stijn1309 Wanneer je de add-on pagina opent en wat naar beneden scrollt, zie je op 'n gegeven moment onder het 'Config' gedeelte het kopje 'Network' met daaronder hetgeen uit mijn screenshot.

Ja dat ziet er als volgt uit:



En dit zijn mijn Shelly instellingen:

[Exigence]

stijn1309 schreef op vrijdag 19 juli 2019 @ 15:21:
[...]


Is mijn eerste en enige MQTT device tot nu toe. Orginele firmware van Shelly. Ik vermoed dat het in mijn installatie van de broker zit. Beide zitten in hetzelfde netwerk!

Ik heb alleen de Add-on geïnstalleerd en daarna niets in de config aangepast/gezet het zou vanzelf moeten werken...

hier de config van de Mosquitto add-on

code:

{
  "logins": [],
  "anonymous": false,
  "customize": {
    "active": false,
    "folder": "mosquitto"
  },
  "certfile": "fullchain.pem",
  "keyfile": "privkey.pem"
}

@JBS Hoe bedoel je te verbinden met de poort die je het ingevuld onder host?

Ik denk dat de de config nog even moet uitbreiden met een username en password en nog wat instellingen. Zie ook de readme op GitHub: https://github.com/hassio...qtt/blob/v1.1.0/README.md

Dan moet je je Shelly met deze gegevens alles naar Mosquitto laten sturen.

[stijn1309]

Exigence schreef op vrijdag 19 juli 2019 @ 15:44:
[...]

Ik denk dat de de config nog even moet uitbreiden met een username en password en nog wat instellingen. Zie ook de readme op GitHub: https://github.com/hassio...qtt/blob/v1.1.0/README.md

Dan moet je je Shelly met deze gegevens alles naar Mosquitto laten sturen.

Ik heb deze handleiding gevolgd: https://www.home-assistant.io/addons/mosquitto/
Daarna kwam ik nog op internet een post tegen dat je geen gebruikersnaam en wachtwoord hoeft op te geven, omdat die deze intern gewoon gebruikt (de add-on).

Heb hem nu toch hard opgegeven wie weet brengt die verandering...

Edit: nog niets...

[Exigence]

Kijk eens in HiveMQ met een subscription op '#' (alle topics) of er uberhaupt iets binnenkomt.

[Yukkie]

Geen idee of je bij de logfiles van Mosquitto kunt, wellicht staat daar nog een hint in wat er mis gaat?

[stijn1309]

Exigence schreef op vrijdag 19 juli 2019 @ 15:54:
Kijk eens in HiveMQ met een subscription op '#' (alle topics) of er uberhaupt iets binnenkomt.

Ok ik heb met MQTT Explorer gekeken en er gebeurt dus niets op de broker....
Heb een test bericht naar de broker gestuurd en die komt wel aan!

Moet de Shelly een bericht sturen naar de broker om zichzelf aan te melden of iets dergelijks?
Of moet ik het nu vooral gaan zoeken in de combinatie van configuration.yml en de shelly instellingen?

[Yukkie]

Blijkbaar kan je Shelly dus niets publiceren naar MQTT, dat moet je dus eerst oplossen. Die configuratie komt later.
Zijn je instellingen in MQTT Explorer exact hetzelfde als in je Shelly?

[Exigence]

stijn1309 schreef op vrijdag 19 juli 2019 @ 16:22:
[...]


Ok ik heb met MQTT Explorer gekeken en er gebeurt dus niets op de broker....
Heb een test bericht naar de broker gestuurd en die komt wel aan!

Moet de Shelly een bericht sturen naar de broker om zichzelf aan te melden of iets dergelijks?
Of moet ik het nu vooral gaan zoeken in de combinatie van configuration.yml en de shelly instellingen?

Ik denk dat je eerst moet uitzoeken waarom het bericht van de Shelly niet bij de broker aankomt. Zodra je dat voor elkaar hebt kun je kijken of je dit bericht met HA op kunt pikken.

[stijn1309]

Exigence schreef op vrijdag 19 juli 2019 @ 16:38:
[...]

Ik denk dat je eerst moet uitzoeken waarom het bericht van de Shelly niet bij de broker aankomt. Zodra je dat voor elkaar hebt kun je kijken of je dit bericht met HA op kunt pikken.

Yukkie schreef op vrijdag 19 juli 2019 @ 16:37:
Blijkbaar kan je Shelly dus niets publiceren naar MQTT, dat moet je dus eerst oplossen. Die configuratie komt later.
Zijn je instellingen in MQTT Explorer exact hetzelfde als in je Shelly?

Ok.. got it wel heel raar dat deze niet aankomen. Ik gebruik dezelfde credentials en ip-adres als in MQTT Explorer. Ik neig ernaar om de Shelly een factory reset te geven.

Edit: WOW!!! hoe scheel kan je zijn... toch ergens een typo waardoor het dus allemaal niet werkte... wat kan je daar soms lang naar staren...

Bedankt allemaal ga nu aan de slag met de config!

[ Voor 11% gewijzigd door stijn1309 op 19-07-2019 16:43 ]

[Yukkie]

Dat ben ik met je eens ;-) maar Ik stel mijn eerdere vraag nog eens: Kun je in je Mosquitto log komen? (Ik ken die HASS plugin verder niet, ik heb Mosquitto los in docker draaien). Kans is aanwezig dat daar nog een hint in staat over wat er mis gaat.

[barrymossel]

stijn1309 schreef op vrijdag 19 juli 2019 @ 15:10:
Ik doe vast iets heel basics fout.. maar ik kom er maar niet achter.

1. Ik heb Home Assistant geïnstalleerd op mijn PI.
2. Toen heb ik de Mosquitto MQTT add-in geïnstalleerd.
3. Account aangemaakt om devices te koppelen.
4. Shelly MQTT geactiveerd en daar het ip-adres ingevuld van de PI met poort 1883
5. In de configuration het volgende ingevuld (had eerst meer maar deze basis doet ook niets):

code:

switch:
  - platform: mqtt
    name: "Garagedeur"
    command_topic: "shellies/shellyswitch25-74516A/relay/0/command"

Er gebeurt gewoon niets heb het ook al geprobeerd met /relay/1 maar zelfde resultaat.

Ergens moet ik iets gemist hebben... maar ik kan het niet vinden.

Zo staat het er bij mij in en werkt het gewoon...

code:

  - platform: mqtt
    name: Garagedeur
    state_topic: "shellies/shellyswitch25-74516A/relay/0"
    command_topic: "shellies/shellyswitch25-74516A/relay/0/command"
    qos: 2
    payload_on: "on"
    payload_off: "off"
    retain: false
    optimistic: false

[stijn1309]

Yukkie schreef op vrijdag 19 juli 2019 @ 16:43:
Dat ben ik met je eens ;-) maar Ik stel mijn eerdere vraag nog eens: Kun je in je Mosquitto log komen? (Ik ken die HASS plugin verder niet, ik heb Mosquitto los in docker draaien). Kans is aanwezig dat daar nog een hint in staat over wat er mis gaat.

Had mijn bericht nog geedit. Het is gelukt... toch een typo ergens waar ik dus 100x overheen heb gelezen

[jossie67]

Ik heb geupdate naar 0.96.1 maar nu kan ik nergens in:
Configuration > General >
vinden waar ik de config files kan laten controleren?
Nog even de release notes gelezen, maar daar kan ik ook vinden, kijk ik er nou overheen?

[PuckStar]

jossie67 schreef op vrijdag 19 juli 2019 @ 21:10:
Ik heb geupdate naar 0.96.1 maar nu kan ik nergens in:
Configuration > General >
vinden waar ik de config files kan laten controleren?
Nog even de release notes gelezen, maar daar kan ik ook vinden, kijk ik er nou overheen?

Ja daar en dan naar beneden scrollen.

[tdw]

redah schreef op vrijdag 19 juli 2019 @ 09:37:
Ik heb een simpele automation om onze Google speaker een melding te geven als de wasmachine (op zolder) klaar is:

code:

- id: wasmachine_klaar
  alias: Wasmachine is klaar
  trigger:
  - platform: numeric_state
    entity_id: sensor.smart_plug_zolder_watts
    below: 1.0
    for:
      minutes: 1
  action:
  - service: tts.google_say
    data_template:
      volume_level: 0.5
      message: De wasmachine is klaar
      entity_id: media_player.google_mini_woonkamer
      language: nl
      cache: false

Ofwel, zodra het wattage onder de 1 watt zakt, komt er een melding. Echter geeft de plug regelmatig ook 'unknown' als state aan. En zodra de state dan weer naar '0' springt vindt HA het een goed idee om de Google speaker te laten praten Ik heb even zitten klooien maar kom er niet uit om te zorgen dat 'unknown' genegeerd wordt.

Ik dacht dat het wellicht handig was om een 'from:' 'to:' te gebruiken, zodat de automation alleen maar triggert als er van >1 naar <1 gegaan wordt, maar krijg dat niet voor elkaar in YAML.

Heeft iemand een suggestie?

Wellicht een https://www.home-assistan...s/binary_sensor.template/ gebruiken? Je zult dan in de template aan moeten geven dat het vermogen >1 watt betekent dat de wasmachine aan staat, en een vermogen van 0 watt of 'unknown' betekent dat de wasmachine uit staat.

Je kunt daarna je trigger aanpassen:
from: 'on'
to: 'off'

En dan zou het gepiept moeten zijn. Ik weet alleen niet of ik dingen nodeloos ingewikkeld maak, en ik heb ook geen flauw benul hoe je zo'n template-string schrijft, maar daar kunnen andere gebruikers je hier mee helpen denk ik

[jossie67]

PuckStar schreef op vrijdag 19 juli 2019 @ 21:17:
[...]

Ja daar en dan naar beneden scrollen.

Ik zie toch niks



Ik draai Hassio op en NUC

[PuckStar]

jossie67 schreef op vrijdag 19 juli 2019 @ 21:25:
[...]


Ik zie toch niks

[Afbeelding]

Ik draai Hassio op en NUC

vreemd. ik heb het wel: https://i.imgur.com/THAxfbB.png
Draai ook Hassio op NUC.

[anboni]

jossie67 schreef op vrijdag 19 juli 2019 @ 21:10:
Ik heb geupdate naar 0.96.1 maar nu kan ik nergens in:
Configuration > General >
vinden waar ik de config files kan laten controleren?
Nog even de release notes gelezen, maar daar kan ik ook vinden, kijk ik er nou overheen?

Je moet even naar je profiel (username helemaal onderaan sidebar) en daar Advanced mode aanzetten. De developers vinden blijkbaar dat het product al dusdanig af is dat ze bepaalde dingen voor domme gebruikers kunnen en moeten verbergen

[MisteRMeesteR]

anboni schreef op vrijdag 19 juli 2019 @ 21:32:
[...]


Je moet even naar je profiel (username helemaal onderaan sidebar) en daar Advanced mode aanzetten. De developers vinden blijkbaar dat het product al dusdanig af is dat ze bepaalde dingen voor domme gebruikers kunnen en moeten verbergen

Idd, zie ook https://www.home-assistan...release-96/#advanced-mode

Advanced mode

As part of Home Assistant 1.0 effort, we’re simplifying the default user interface. We’re doing this by hiding certain configuration options like the customize panel behind a new “advanced mode” toggle. You can find this toggle on your profile page.

Advanced mode is only available to admin users and is a per-user setting. Enabling it for yourself won’t enable it for other admins.

[Mars Warrior]

Je kijkt ff een weekje niet, en er zijn weer talloze repositories aan HACS toegevoegd



(de lijst gaat nog een heel stuk verder zoals je aan de scrollbar rechts ziet...)

Deze "store" haalt ook mijn grootste probleem weg, namelijk het gedwongen upgraden van components die "broken" zijn. Ik kan hier gewoon een versie kiezen die mij uitkomt



HACS kan erg veel tracken. Je kunt ook je eigen repositories toevoegen natuurlijk:

• Custom integrations (components/platforms/custom_component) for Home Assistant
• Custom plugins (cards/rows/mods) for Lovelace
• AppDaemon apps for AppDaemon
• Themes for the frontend integration in Home Assistant
• "python_scripts" for the python_scripts integration in Home Assistant

Als nu de built-in components ook gaan voldoen aan het HACS formaat, dan kunnen die voortaan ook via de store geïnstalleerd, gedowngrade en geupgrade worden

Upgraden wat jij wilt en wanneer het jou uitkomt. Leuker kan HACS het niet maken

(Let op de Breaking Changes Component, die is voor mij iha het signaal om wel of niet te upgraden)

[ Voor 4% gewijzigd door Mars Warrior op 19-07-2019 22:18 ]

[Hmmbob]

Hmmm, ziet er interessant uit. Is dat een Hass.io ding, of ook standalone/Docker?

[Mars Warrior]

Hmmbob schreef op vrijdag 19 juli 2019 @ 22:31:
Hmmm, ziet er interessant uit. Is dat een Hass.io ding, of ook standalone/Docker?

Is een custom component, dus die moet je gewoon met de hand installeren vanuit een zip file.
Op de site staat een tutorial hoe je HACS moet integreren in je hass omgeving. Is maar een paar minuten werk. Daarna hass herstarten en je kunt je uitleven

Het vervangt custom_updater. Die moet je dus ook verwijderen omdat die twee conflicteren.

[ Voor 8% gewijzigd door Mars Warrior op 19-07-2019 22:39 ]

[Hmmbob]

Yep, was me al aan t inlezen. Wat ik nog niet gevonden heb is zo'n lijst als uit jouw screenshot - kan je die ook benaderen voor je HACS installeert?

[Mars Warrior]

Hmmbob schreef op vrijdag 19 juli 2019 @ 22:39:
Yep, was me al aan t inlezen. Wat ik nog niet gevonden heb is zo'n lijst als uit jouw screenshot - kan je die ook benaderen voor je HACS installeert?

Geen idee. HACS verwijst naar een hele rits Github repositories. Na het installern van HACS moet je ook ff wachten totdat HACS alles heeft gedownload. Dat duurt bijna langer dan het installeren...

Ik tel nu zo ff snel 80 integrations en 80 plugins (voornamelijk voor Lovelace)

[ Voor 9% gewijzigd door Mars Warrior op 19-07-2019 22:48 . Reden: Aantallen erbij gezet ]

[lubbertkramer]

Hmmbob schreef op vrijdag 19 juli 2019 @ 22:31:
Hmmm, ziet er interessant uit. Is dat een Hass.io ding, of ook standalone/Docker?

Misschien in toevoeging op de uitgebreide post van @Mars Warrior. HACS is de opvolger van custom updater en is puur bedoeld om custom components/plugins etc te beheren. Voor custom updater / HACS moest je zelf in de gaten houden of een custom component geupdate was. Je kunt hier inderdaad sinds kiezen naar welke versie je update.

Let wel op, in tegenstelling tot het bericht dat HACS en de componenten geen breaking change hebben is dit niet helemaal waar, zowel HACS als de plugins hebben breaking changes en soms moet je daarvoor de changelog lezen of de releasenotes, zie de release notes van custom header (23 dagne geleden) of die van HACS zelf als voorbeeld waar dusdanige breaking changes zijn dat het niet meer werkt ondanks dat je niets veranderd aan je code.. Goed lezen is net als de release notes van HA zelf wel een ding voordat je update!

[ Voor 11% gewijzigd door lubbertkramer op 19-07-2019 23:02 ]

[martinvdm]

Hmmbob schreef op vrijdag 19 juli 2019 @ 22:39:
Yep, was me al aan t inlezen. Wat ik nog niet gevonden heb is zo'n lijst als uit jouw screenshot - kan je die ook benaderen voor je HACS installeert?

Je zou het hier vandaan kunnen halen
https://github.com/custom...cs/tree/data/repositories

[anboni]

Trouwens even een noobvraag (ben gisteren met hass begonnen). Ik ben aan het stoeien met 'n Tradfri hub en wat lampjes, maar als ik iets nieuws aan de hub koppel wordt dat niet gedetecteerd door hassio tot ik de hub verwijder (uit integration) en opnieuw toevoeg. Hoort dat zo, of zie ik iets stoms over het hoofd?

Ik lees trouwens ook nog tegenstrijdige berichten over de Tradfri motion sensor. Is de state daar nou inmiddels wel of nog steeds niet van uit te lezen? Of kan dat alleen maar als je gebruik maakt van 'n RaspBee/ConBee? (die laatste heb ik sowieso al besteld, minder stekkers is altijd beter)

[DvD77]

jossie67 schreef op vrijdag 19 juli 2019 @ 21:10:
Ik heb geupdate naar 0.96.1 maar nu kan ik nergens in:
Configuration > General >
vinden waar ik de config files kan laten controleren?
Nog even de release notes gelezen, maar daar kan ik ook vinden, kijk ik er nou overheen?

Advanced mode aanzetten.... zit onder je gebruikersnaam links onder, daarna heb je weer controle van config files

[Mich]

Mars Warrior schreef op vrijdag 19 juli 2019 @ 12:18:
[...]

Ik beheer(de) 5 Home Assistant installaties, en geen van allen werken perfect: ze hebben allemaal problemen met de geïntegreerde componenten die kleine tot grote problemen vertonen. Sommige zonder gevolgen voor de eindgebruiker, en andere die behoorlijk irritant zijn voor de eindgebruiker.

Toch willen ze allemaal hass blijven gebruiken

[...]

Ik heb werkelijk niks tegen refactoring zoals netjes in het blog staat aangegeven: dat heeft een belangrijk doel om dingen eenvoudiger te maken voor het beheer en de ontwikkelaars.
Echter als je elke 2 weken dit soort breaking changes hebt, dan is er naar mijn mening en ervaring iets mis met de opzet (architectuur) van het geheel, zeker als elke technische wijziging doorkomt bij de eindgebruiker.

Zoals ik in het architectuur issue (https://github.com/home-assistant/architecture/issues/192) al eerder heb aangegeven zijn er zat mogelijkheden - hass toont dat aan namelijk - om met veel minder impact en werk voor de devs de software te ontwikkelen en stabiel te krijgen met zo min mogelijk overlast voor de eindgebruiker.

Ook de community laat recent met HACS zien dat het allemaal ook veel eenvoudiger en overzichtelijker kan om plugins en updates te kiezen en te installeren.

Door de enorme hoeveelheid werk om elke 2 weken de problemen met 5 hass installaties op te lossen, gecombineerd met de kennis en ervaring uit mijn dagelijks werk (architect / manager van complexe IoT systemen) ben ik op een gegeven moment mijn energie gaan steken in een opzet die het onderhoudswerk drastisch omlaag brengt: het gebruiken van plugins die gekoppeld zijn via MQTT én perfect via MQTT discovery integreren met hass:

• Alle op ESP* gebaseerde systemen (Tasmota, ESPHome via MQTT, etc.)
• otgw2mqtt, koppelen van Opentherm kachels (meervoud) aan hass.
• Zigbee2mqtt, waar ik veel heb lopen testen voor de hass integratie
• DSMR Reader, waar ik in 2016 al (2017 gerealiseerd) een issue voor MQTT integratie heb ingediend
• zwave2mqtt, waar ik na grote problemen met de hass zwave component ook maar een issue voor MQTT/ hass integratie heb ingediend en die nu in beta is.

Het kenmerk van al deze modules of hoe je ze ook noemen wilt is dat ze:

• Sterk in ontwikkeling zijn, dus veel wijzigingen hebben, net als hass
• Ze hebben het afgelopen jaar (voor zover ze er toen al waren) icm hass op alle 5 de installaties geen problemen veroorzaakt: ze doen het gewoon altijd vanwege de standaard koppeling en integratie met hass over MQTT. Refactoring zonder gevolgen voor de buitenkant en gebruik.
• Ik zonder problemen ook meerdere instanties kan koppelen itt de geïntegreerde hass componenten. Dus je vakantiehuisje in Spanje (Zigbee en Wifi) is gewoon te zien in hass
• Ik zelf kan mixen en matchen qua versie: ik kies gewoon het juiste label/versie voor de Docker container en ram op de deploy knop in Portainer. Problemen? Dan weer ff terug en alles werkt weer.

Ik ben een grote fan van hass en steek dus eigenlijk heel wat tijd en energie in hass, maar dan via de MQTT route. Ik heb factoren minder werk bij elke update van hass (en wacht daarom maar tot een .3 of .4 versie om dat werk nog verder te reduceren) en steek mijn tijd liever in het maken van een mooie Lovelace interface, automations en het uitproberen van custom components die ik simpel installeer via HACS

Wat is voor jou het voordeel om otgw2mqtt te gebruiken ipv de OTmonitor? Hier kan je ook vrij uitgebreid je mqtt instellen. En je hebt nog een en interface om op terug te vallen.

[LA-384]

martinvdm schreef op zaterdag 23 februari 2019 @ 18:53:
[...]

Oplossen net als ik met een pulsedrukker en een opbouwdoosje en hierin de Fibaro/qubino.
[Afbeelding: Rolluik]

Weet je nog welke producten dit precies zijn? Ik zit met hetzelfde probleem dat de draaischakelaar te weinig ruimte heeft en dit ziet er netjes uit.

[martinvdm]

LA-384 schreef op zaterdag 20 juli 2019 @ 12:05:
[...]

Weet je nog welke producten dit precies zijn? Ik zit met hetzelfde probleem dat de draaischakelaar te weinig ruimte heeft en dit ziet er netjes uit.

Ja hoor:
Hager Berker Basiselement - Jaloezie impulsdrukker 503520

Hager Berker S/B - Bedieningswip 16258989
Dit is de Bedieningswip dubbel jaloezie

Hager Berker S/B - Opbouwbak 10418989
Dit is het opbouwbakje

Hager Berker S.1 - Afdekraam 10118989
Dit is het afdekraam

Daarin heb ik dus een Fibaro Roller Shutter gebouwd. Het is wel enorm proppen en je moet het opbouwbakje een beetje wat randjes aan de binnenkant wegknippen maar resultaat is idd mooi. Werkt al jaren prima.

[Edmin]

martinvdm schreef op zaterdag 20 juli 2019 @ 12:29:
[...]


Daarin heb ik dus een Fibaro Roller Shutter gebouwd. Het is wel enorm proppen en je moet het opbouwbakje een beetje wat randjes aan de binnenkant wegknippen maar resultaat is idd mooi. Werkt al jaren prima.

Andere mogelijkheid: stop de Fibaro in de centraaldoos (indien die bereikbaar is). Ik kon geen N bijtrekken naar de wanddoos omdat de buis helemaal vol zat. Dit was voor mij een prima oplossing.

[Mars Warrior]

Mich schreef op zaterdag 20 juli 2019 @ 07:48:
[...]
Wat is voor jou het voordeel om otgw2mqtt te gebruiken ipv de OTmonitor? Hier kan je ook vrij uitgebreid je mqtt instellen. En je hebt nog een en interface om op terug te vallen.

Heeft te maken met een stuk historie. Ik moest - want winter - de kachelbesturing voor deze hass installatie stabiel krijgen en heb toen dat stukje python gekozen dat ook alles doorgeeft wat nodig was. En dat draait nog steeds stabiel, geen omkijken naar

Zelf gebruik ik nu otmonitor: geeft minder door over mqtt, maar heeft ook een relay waarmee ik de ingebouwde otgw component van hass kan testen. Die geeft nog steeds talloze foutmeldingen of valt volledig uit omdat hij de verbinding kwijt is.

Misschien dat ik het ooit nog allemaal rechttrek, maar het werkt al zo stabiel sinds 2014, dus waarom zou ik??