En is deze ook gemakkelijk te integreren met HA? Want ik zie blijkbaar enkel een integratie met Dobiss NXT?
Klopt, is geen integratie voor⊠Het is wel mogelijk op basis van ethernet of op basis van canbus, maar het is wel wat nadenken en programmerenâŠ
Created a small tool to debug CAN traffic on the SX-Evolution. Posting this here as it might be helpful for someone. 
Cool, thnx for sharing!! Too bad the dimmers are constantly reporting state on canbusâŠ
Are you going to create an integration for HA based on evolution?
Helemaal geen probleem, ben de laatste tijd ook niet meer zo intensief bezig met mân Dobiss/Home assistant. maar daar zou je me nog altijd heel hard mee uit de nood helpen
Hey, Ik heb recent een .net versie van dobiss2mqtt van SpoBo gemaakt, Deze bevat ook een restapi:
docker: https://hub.docker.com/r/vandenboschvincent/dobissconnectorserviceapp
Momenteel enkel getest met AMBIANCEPRO
Zeker welkom om is te testen en laat maar weten als er problemen zijn.
1 Like
Is het niet beter om een canbus project te maken ipv via TCP, zo heb je toch instant status van je relays?
Ik heb gemerkt dat als een project aangesloten is via canbus de native dobiss app niet meer werkt. Maar idd op sommige vlakken is via canbus beter.
Hmm, dat is vreemd, zou normaal geen impact mogen hebben, want is een bus systeem, ofwel heb je een Jumper staan dat de canbus adapter je laatste endpoint is
Aangezien dit topic mijn inspiratie was wil ik graag mijn Dobiss GitHub project
hier delen. Na enkele maanden âprutsenâ heb ik een werkende module om de signalen van de Digitale drukknoplijn ( DO0501, DO0502, DO0504, ⊠) met een microcontroller. Zo kan ik alle logical van de Dobiss modules ( DO5450 en DO5011) vervangen met mijn eigen Python aansturing. Python gebruikt CAN-bus om de modules aan te sturen en zo de nodige lichten, screens en ventilatie te bedienen.
Eindelijk kan ik zelf de functionaliteit van mijn lichtschakelaren aanpassen zonder beroep te doen op een electricien met de proprietary software.
De volgende functionaliteit om te ontwikkeling is een integratie met Home Assistant, zowel lichten aansturen vanuit Home Assistant als Home Assistant aansturen met lichtschakelaren.
3 Likes
Mooi, volgende week eens bekijken! Ik gebruik zelf de canable USB adapter, rechtstreeks op HassOS aangesloten, geen extra breadbord nodig etcâŠ
Ik maak ook gebruik van python can, en eigen custom component om de waardes over de canbus te gebruiken voor de States van de verlichting etcâŠ
Edit: ok, nu lees ik het tegoei, jij vervangt heel de max200! Netjes, moest deze bij mij ooit stuk gaan :+)
Je zegt properietary software? Welke software heb je dan niet die je elektricien wel heeft?
De Ambiance PRO Tool. Vroeger had ik er een demo versie van. Ik zie dat die ondertussen vrij te downloaden lijkt, dus de helft van mijn motivatie voor dit project lijkt dus ongegrond.
Maar bij mij is de hoofd module het aan het begeven en herstart die meermaals per dag. Het hele systeem reageert dan niet meer omdat de lichtschakelaars niet meer uitgelezen worden. Nu kan ik de andere modules verder gebruiken en indien nodig defecte modules vervangen met een ander merk relays of dimmer.
1 Like
Wow dat vind ik een goed idee.
Mijn oplossing (CAN HAT op pi + wat rommel in software) werkt niet altijd even goed (ha/pi updates zijn leuk), hopelijk is een Pico wat stabieler.
Op termijn zou ik ook graag op een servertje hosten ipv op een pi, en dan zijn HATs/USB dongles toch ook weer niet zo handig. De RS485 dongle/HAT zijn al vervangen door een Pico met ESP Home. Mijn eerste plan was enkel die CAN logical in de ESP Home steken, maar rechtstreeks de 1wire doen lijkt met wel een pak krachtiger.
Ik zou precies wel liever er een ESPHome component van maken ipv zelf iets te bricoleren. Als het lukt, zet ik de config online voor de volgende
So far I have discovered (based on the work of wriswith):
The Dobiss button bus is just a Dellas 1wire bus (as expected), where all of switches are identified by a DS2411 (or possibly DS2401) Silicon Serial Number chip.
Closing the switch contacts somehow connects the chip to the bus, so they only appear on the bus if a switch is pressed.
This is different from what I thought initially (that all devices are some kind of GPIO chip, always on the bus), so when I was trying to get my ESPHome code to work, it never discovered any devices, since the bus is emptyâŠ
I also needed a 1k pullup, not the 5k typically mentioned.
Due to this architecture, I think a custom ESPHome component will be needed, but I have good hope that should allow a Pico/ESP8266/ESP32 with a CAN bus adapter and a 1k pullup to replace the role of the master relay box.
My end goal is to have the basics (switch â relay) embedded in the single device, and have it work independently of HA, but still expose every individual user action to HA, so more complex automations can be done in HA instead.
1 Like
Hope I donât annoy people with the updates, but Iâm excited 
With some experimenting some C++ mangling and some cursing, I was able to get the following config working on my fork of esphome. I wouldnât mind some input/opinions on a few things, I put some comments in the yml.
The loop only happens ever 16ms at most, I think this is slower than the genuine master, but seems fast enough to me.
Next up is getting the CAN part to work like Iâd like it to. It doesnât look like it wouldnât be too difficult with actions, lambdas and a CAN bus component, but I think I would prefer a custom platform that can handle the complexities of internal state changes (mainly for if the power fails).
relevant YAML snippet with requests for feedback :)
# I'm now modifying the built-in one-wire component, but I doubt my change would be accepted in a merge. (?)
one_wire:
- platform: gpio
pin: GPIO4
scan: true # This is the hack variable I'm using now
# I was thinking this would work (with an external component):
one_wire_scanning:
- platform: gpio
pin: GPIO4
# Aside from the scanning every loop, it also logs never before seen devices which makes getting the addresses of switches easy.
# This will/should be an option (disabled by default) for performance reasons though.
# In my current implementation, the dallas_serial is a binary sensor that checks on every loop if it is in the devices list and sets its state accordingly.
# i.e. the sensor represents the actual state of the physical button.
# I'm more optimistic this could be merged upstream.
binary_sensor:
- platform: dallas_serial # Name suggestions welcome (?)
address: 0xXXXXXXXXXXXXXX01
id: bs_gang_r
name: Button Gang R
on_click:
min_length: 0ms # Q3: No need for additional debouncing, the 16ms loop cycle is slow enough (?)
max_length: 350ms
then:
# This is a zigbee light, so it has to go via HA.
- homeassistant.action:
action: light.toggle
data:
area_id: kitchen
- platform: dallas_serial
address: 0xXXXXXXXXXXXXXX01
id: bs_gang_l
name: Button Gang L
on_click:
min_length: 0ms
max_length: 350ms
then:
- light.toggle: l_gang
light:
- platform: binary
id: l_gang
name: Lamp Gang
output: relay_gang
output:
# This works, but cannot keep track of state, so gets out of sync if ESPHome devices or relay box dies
- platform: template
id: relay_gang
type: binary
write_action:
- canbus.send: !lambda return {0x01, 0x04, state, 0xFF, 0xFF};
# Not yet implemented, but I think this would make sense:
# If you have requests for additional properties to add, feel free to ask
- platform: dobiss_can # Name suggestions welcome (?)
id: relay_gang
module: 1 # first byte in payload
relay: 4 # second byte in payload
3 Likes