Als je je dus baseert op de messages die op de canbus verschijnen, dat zijn niet dezelfde als de commandos om iets te sturen
Die prefix is normaal anders probeer dit eens?
cansend can0 00800102#00410401
cansend can0 00800102#00410400
Ja ik verwar de state dus met aan/uit commando’s… Zou je een voorbeeld kunnen geven van zo een ghost programma? Hoe je dat precies opsteld in Maxtool?
Thanks, ik probeer het even 
Ik heb een programma gemaakt dat iets doet met een temperatuur regime, iets aan / uit zetten… Maar ik heb helemaal geen temp sensor op mijn dobiss , dus dat doet niks
Maar het programma gaat wel aan/uit, die state vang ik op en dan schakel ik iets in HA
Je moet ook in HA de juiste state hebben, want stel dat HA denkt dat de lamp aan is , maar feitelijk is hij uit… als je dan de lamp aan doet in HA , dan gaat hij niet aan je
Daarom dat ik met een state sensor werk, zodat de statussen van de lampen overeen komen
Ik gebruik dus die value_template …
Als je nog niet werkt met statussen , zou je voorlopig de assumed state op false kunnen zetten, dan kan je altijd iets aan zetten in HA ookal stond het al aan… Dat heb je je zo geen slider op je lamp, maar effectief knopjes (bliksem schichten)
als ik dit doe:
cansend can0 00800102#00410401
dan zie ik op mijn canbus de message zelf EN de state van de lamp
Deze is dus belangrijk om mee te sturen: 00800102
ALsook een toggle commando werkt ook, maar gebruik ik niet, omdat ik toggle via HA …
cansend can0 00800102#00410402
Hierbij ook een dummy programma, dat een sfeet aan zet wat niks doet…
Als ik dan op een drukknop duw, doe ik via een automation een actie, hieronder bv de stoffzuiger aanzetten:
Ik toggle eigenlijk via een knop het programma… als dat aan/uit ot uit/aan gaat, dat signaal vang ik op …
- alias: Stofzuiger boven aan
initial_state: 'on'
trigger:
- platform: state
entity_id: sensor.dobiss
from: '01'
to: '00'
attribute: '570f'
- platform: state
entity_id: sensor.dobiss
from: '00'
to: '01'
attribute: '570f'
condition: []
action:
- service: script.turn_on
entity_id: script.dreame_clean
Hoe kom je precies aan die 00800102? Dat is het extended ID om aan te sturen dan? Wat ik ook probeer, ik krijg enkel states te zien in de logs. Welke firmware versie draait er op jouw max200?
Heb je ook de webserver destijds gekocht? die was aangesloten via een can2usb adapter, deze webserver stuurde CAN messages, daarvan heb ik het traffic van gecapteerd, anders was ik nooit de commandos te weten gekomen
FW versie 6.2, maar dat staat daar los van… Die 00800102 is echt wel belangrijk om mee te sturen, dat is een soort van ID, de ID van de webserver destijds
denk dat de 00800102 , is de identifier van de message
Geen webserver aanwezig hier 
dus dat ID heeft waarschijnlijk weinig zin hier… net even getest maar geen effect tot nu toe… Ik ben aan het overwegen om tcp of serial te gaan gebruiken om aan te sturen, en canbus enkel voor de states.
Ik heb ook geen webserver meer, maar je moet de commandos sturen met de juiste ID zodat de maxtool “denkt” dat het van de webserver komt! DUs wel zeer belangrijk!!
Heb eens geprobeerd maar opnieuw geen effect, zou dat ID uniek zijn per installatie? Moeilijk om zoiets te weten te komen…
switch:
- platform: template
name: "CAN Bus Switch"
id: canbus_switch
turn_on_action:
- canbus.send:
can_id: 00800102
use_extended_id: true
data: !lambda return {00, 41, 06, 01};
turn_off_action:
- canbus.send:
can_id: 00800102
use_extended_id: true
data: !lambda return {00, 41, 06, 00};
optimistic: true
canbus:
- platform: esp32_can
id: first_canbus
tx_pin: GPIO5
rx_pin: GPIO4
bit_rate: 125kbps
can_id: 00800102
use_extended_id: true
[12:36:18][D][canbus:032]: send extended id=0x000c3566 rtr=FALSE size=4
hier is een vb script met python, daar is ook de arbitration_id die belangrijk is
nee, dat is niet uniek per installatie
Maar als je de switch aanzet, zie je dan totaal geen message op je canbus verschijnen? Je moet de message sowieso zien, ookal is hij verkeerd!
Als je totaal geen message ziet, dan is het eerder een probleem om je bericht te sturen op je canbus! En niet de message zelf
je bitrate is ook belangrijk hé! ik doe deze commandos om mijn canabla online te brengen, denk dus op bitrate 1000
subprocess.call(['modprobe', 'can'])
subprocess.call(['modprobe', 'can_raw'])
subprocess.call(['modprobe', 'slcan'])
os.system("apk add /config/python_scripts/canutils.apk")
os.system("slcand -o -c -s4 /dev/ttyACM0 can0")
os.system("ifconfig can0 txqueuelen 1000")
os.system("ifconfig can0 up")
Ik zie idd geen message passeren bij het versturen. Tijd om mijn ESP32 opstelling eens te controleren. Ik gebruik ook deze transceiver en niet de mcp2515. Dat speelt misschien ook wel een rol…
ja, dan ligt daar eerder je probleem, en niet de code!
Maar je kan wel messages lezen? de candump / log lukt wel ?
Lezen lukt, schrijven niet
net even gecheckt, bitrate moet idd 125000 zijn
ik heb nu voor express een verkeerde ID genomen, lamp gaat idd niet aan, maar ik zie wel de message verschijnen