Gå til innhold
  • Bli medlem
Støtt hjemmeautomasjon.no!

kolaf

Medlemmer
  • Innlegg

    19
  • Ble med

  • Besøkte siden sist

  • Dager vunnet

    1

kolaf vant dagen sist 28. januar 2023

kolaf hadde mest likt innhold!

Hjemmeautomasjon

  • System
    Home Assistant

Nylige profilbesøk

Blokken for nylige besøkende er slått av og vises ikke for andre medlemmer.

kolaf sine prestasjoner

Kabelfører

Kabelfører (6/16)

  • Ett år inn
  • Samarbeidspartner
  • Første innlegg
  • Samtalestarter
  • Uke én ferdig

Nylige merker

9

Nettsamfunnsomdømme

  1. Om jeg husker rett er det integrasjonen som setter det attributtet. Settes i forhold til en prosentvis terskel av døgnets høyeste pris, tror jeg. Terskelverdier kan settes i konfigurasjonen.
  2. Strålende. Ingenting er bedre enn at noen andre tar tak og lager der min tid ikke strekker til. Om dette blir fulgt opp så bytter jeg sikker jeg og 😄
  3. Beklager litt fravær. @torhaalaEr fortsatt bare read only såvidt jeg vet. @BalleClorin Takk, skal se på det straks jeg får tid igjen. Har endelig fått ny feedback på min PR til HA, så får forhåpentligvis tatt tak i den etterhvert også.
  4. Ny versjon 0.1.5 er lastet opp. Ikke mye nytt, men tror jeg omsider har fått has på stabiliteten. Homely sitt API er ganske ustabilt, men jeg tror jeg nå endelig håndterer det på en god måte.
  5. We are slowly getting there. New version 0.1.4 has been uploaded. The last version 0.1.3 has been quite stable for the past 24 hours, so I believe I have resolved the issue with the websocket disconnecting from time to time. This version solves an issue where the instability of the Homely API endpoint causes the sensors to be "unknown" if it fails during a poll. They will be marked as unknown until the next poll five minutes later. I have tried to rectify this by allowing it to fail two times before throwing an error. Since we still probably are connected to the web socket the user should not notice this at all. This also means that if everything fails can take 15 minutes before the system shows as unavailable/unknown. 0.1.4 also adds support for "Heat Alarm" and "Motion Sensor 2 Alarm" model names. Also, to follow-up the yale doorman issue above, it seems that this device is not included in the data feed from Homely, unfortunately.
  6. Ny feil følger. Versjon 0.1.3 er lastet opp. Om du følger readme til https://github.com/kolaf/homelypy og sender meg json filen så får jeg sikkert laget støtte for dørlåsen etterhvert.
  7. Lastet akkurat opp Homely 0.1.2 for HA som fikser problemer med disconnect etter en stund. Håper den kjører stabilt nå. Google drive
  8. I just updated the existing version 0.1.0 to correctly handle alarm states for the house. I have left the code that polls every five minutes, so this should still work as a fallback if the socket disappears.
  9. I have now uploaded version 0.1.0 to Google Drive. It is updated to use my newly pushed homelypy 0.1.0 where I have finally gotten the websocket to work. This is thanks to very useful help from this implementation: https://github.com/hansrune/homely-tools. The trick is to use socketio instead of the python websocket-client library. The latest version of integration should support streaming updates of entities, so that door sensors, alarms, et cetera are updated in real time. I have not had a chance to run this for a longer period yet, so I am not sure what the stability of the connection looks like. It might well be that I will have to improve the reconnection functionality. Let me know how this works for you.
  10. If anyone wants to check it out you can download version 0.0.2 from this location: https://drive.google.com/drive/folders/1D-obD-u7v_-Q1A0Ik1d_gXdq4WpDZwy0?usp=share_link It should be as simple as creating a folder "custom_components" inside your HA configuration folder, create a folder "homely" beneath this and unpacking the files into the homely folder. After restarting HA you should be able to add the integration through the integration page. It supports basic states and binary sensors for the devices I know about. If your device is missing I need a dump to know the model names. I have also added a basic alarm control panel entity. This is very restricted since we do not have write access to the API, but at least it should show the arming state of the alarm system. The system still relies on polling every five minutes, so do not expect to see every door and window opening and it can take up to 5 minutes before an alarm state is updated. I'm still waiting for my initial pull request with the sensor entities to go through, it is taking a while longer than expected since the response from their site has been very slow. In the meantime we can play around with this. If anyone has any experience with the homeassistant alarm entitis I would be glad to learn since this version with non-functioning buttons will probably not be accepted. Thanks. It is a shame that you did not get anywhere with the websocket since this is required to make an alarm system truly useful. How often do you poll for state updates? I chose five minutes as a compromise, but more often would be better :-). I have not installed my door lock yet (it's lying on a shelf), but I am considering joining this directly in homeassistant instead of through homely.
  11. Still waiting for the pull request.
  12. Takk. Testet og nå får jeg temperatur 😄
  13. I updated to your config file an hour ago, but I still do not see any temperature measurements:
  14. This is strange, I did not see any of the values from your screenshot in the logs for my plug. I have the following definition file, and no unknown or on captured reports in the debug logs. const fz = require('zigbee-herdsman-converters/converters/fromZigbee'); const tz = require('zigbee-herdsman-converters/converters/toZigbee'); const exposes = require('zigbee-herdsman-converters/lib/exposes'); const reporting = require('zigbee-herdsman-converters/lib/reporting'); const extend = require('zigbee-herdsman-converters/lib/extend'); const e = exposes.presets; const ea = exposes.access; const definition = { zigbeeModel: ['4512749'], // The model ID from: Device with modelID 'lumi.sens' is not supported. model: '4512749', // Vendor model number, look on the device for a model number vendor: 'Namron', // Vendor of the device (only used for documentation and startup logging) description: 'Namron thermostat plug', // Description of the device, copy from vendor site. (only used for documentation and startup logging) fromZigbee: [fz.on_off, fz.electrical_measurement], // We will add this later toZigbee: [tz.on_off], // Should be empty, unless device can be controlled (e.g. lights, switches). exposes: [e.switch()], // Defines what this device exposes, used for e.g. Home Assistant discovery and in the frontend }; module.exports = definition;
  15. I purchased one a few weeks ago. It was not natively supported by zgibee2mqtt so I had to hack together a definition file for it. It is weird that they call it a thermostat plug since it does not offer temperature measurements. I was not able to find any data from it that has anything to do with power measurements, either, but I might have done something wrong when building my own definition file. This is how it looks now: Unless someone figures out a better way to integrate it and discovers the missing features I would keep away from it.
×
×
  • Opprett ny...

Viktig informasjon

Vi har plassert informasjonskapsler/cookies på din enhet for å gjøre denne siden bedre. Du kan justere dine innstillinger for informasjonskapsler, ellers vil vi anta at dette er ok for deg.