pojd / can Goto Github PK

Change the 2 joined maps of canID -> output number -> port and bit to 2 distinct maps. First would be static of output -> port and bit and could be hardcoded in the header of canRelay now. The second would just map canIDs to output numbers and would be stored in EEPROM and shall be able to be changed over CONFIG messages sent over CAN to the relay (this time it needs strict acceptance filter only for the node ID)

CanSwitch should only know it’s nodeID and send can messages for that ID to up to ID+# of inputs (already the case). Change relay logic to have an array of mappings from IDs to individual port bits according to the final schema.

• Move dao and can there
• Move it to separate git project = piclib

For some reason some have error can set. Perhaps try longer sleep? Seems it is not the case for all CAN switches though. Perhaps try with full CAN termination on both ends?

New message type of button press to mimic button pres on CanSwitch only. to be able to stress test the whole system by simulating sending can messages from multiple can switches to see the real power consumption and thus potential voltage drop then

Since they are also used for sending CAN traffic, therefore would raise plenty of false triggers. So we have to go down to 6 input pins only really

To be able to save and use all PORTB pins for inputs. Also routing would be nicer on the board thanks to this. Perhaps support even for older PCbs, but resolder the paths. Set CONFIG3H.CANMX = 0 according to datasheet. Input 7 and 8 are shared with PGC and PGD. All input ports are in the end available on the PCB, so all good.

At the moment, canRelay replies are the same regardless the floor since the can ID is always 400. Change this so that it contains floor instead of 0 for node ID. Solves just the issue of odroid listening for complex reply in case multple complex get would be sent at the same time to all floors.

1 quarter a sec blink - push button pressed, followed by

7/8sec long blink = send OK
2blinks a sec = sending problem

Number of operations is rather small and it is a waste to use all 8 bits for that. So update to only use some bits of the data for the real switch operations (toggle on and off), use the remaining bits for firmware version, perhaps number of switches done (since we have no timer we can at least see if switches live long or get bounced every now and then), plus a flag set to 1 if there is any error registers non zero from CAN (1 bit).

Since I would need canSwitches with 8 independent lights attached to it in max cases. The code should be able to handle all PORTB pins. This also means I will have to check the actual value of the input pin to only react on key press and not depress

Since it would be matching both the nodeIDs in EEPROM (dao) as well as the value seen on the line using cansend utility since all these are using HEX

• Can a dao bude taky využito novým projektem CanRelay - novej širší filtr pro všechno normal messages, ne heartbeat a ne config a jen jedno patro - čte z eeprom.
• Dle canID pak jen přepne output pin - je úplně jedno co to je za místnost, jen prostě pro floor jedna odečte 10000000 a má číslo, toto číslo pak přepne v portech - potřebuje maximum output portů a asi radši maximum recieve bufferu
• Floor bude novej data type, využije jenom canRelay

It seems the timer is kicked in every 10secs as opposed to every second

stress testing. wire up all input pins of all can switches together to be able to simulate all switches at once. observe the current drawn.

And allow this value to be changed over CAN too so that PROD nodes can be turned to DEBUG nodes as needed

Utilize sleep modes in canSwitches - Look at datasheet how complex it would be. It may save some voltage drops across the line. Look into power mode of the transceiver too

Send complex get to a relay in infinite loop fully utilizing CAN and CanRelay is then dropping some of them, including all key presses from switches. Probably does not anticipate that load and read all registers it should, so fix it.

Current dao implementation has some issues, it does not store the values properly. In addition to that the logic for checking invalid values does not work either - it is always 0xFF (the invalid values read)

• Nodes.h - enum se vsema mistnostma, správně ID pro ně - první bit je patro
• Novej projekt CanSetup - jen zapíše eeprom dle nastavení - setupCanSwitch (kitchen - enum). SetupCanRelay(1 bit floor). Použije Nodes.h a can a dao library

Enhance heartbeat and complex get messages by also reporting the voltage levels

Simply save PORTA, PORTB and PORTC anytime it is changed? Maybe just mark which one got change in the interrupt routine and then let the main thread handle that and update using DAO

I need to know the list of rooms and number of individual wall switches in there. Duplicate switches for the same light are supported too, but would result in different canIDs, so I need to know the full list in order to update the relay mappings for both floors. Flash new firmware to floors then, perhaps increase the counter of firmware then too

• Think it over. A test first flashing a node with an ID, then testing that against other CAN? Or maybe together with CanRelay somehow? But the number of flashes is limited per each chip, so this may be tricky

Measure current drawn by each. Test it can send CAN traffic over, check the CAN errors. Perhaps increase the transceiver timeout if errors still occur? Could have been a glitch actually.

Novy model dat pro CanSwitch.

bit 7 = switch - přepne světlo (tj aktualni funkce dneska)
bit 6 = zapnutí (pouze pokud bit 7 je 0)
bit 5 = vypnutí (pouze pokud bit 7 je 0)
bit 4 = request na stav (pouze pokud bity 7 a 6 a 5 jsou 0)

0b10000000 přepne světlo jako dneska canSwitch
0b01000000 zapne světlo nezávisle na předchozím stavu
0b00100000 vypne světlo nezávisle na předchozím stavu

Navic canID 0 pro dane patro take plati to nahore (tj. bit 7 prepne vsechna svetla, bit 6 nastavi vsechna svetla na zapnuto, ...)

Navic pro canID 0 je navic bit4 request, aby CanRelay automaticky odpovedel se stavem vsech PORTA, PORTB a PORTC

Protect against potential sporadic multiple messages for one nodeID other than floor. I.e. from light switches.

Update heartbeat messages for CanSwitch and also complex replie sfor CanRelays to contain firmware version and time since startup

can, dao and many other things have changed, so make sure CanSwitch still works fine

Think over how to fix this - typically when a CANBUS error happens, now cannot be waken up at all...

Since it would be used in DEBUG only anyway...

Latest changes with latest boards turned some of the README invalid since we are no longer mapping ports to outputs easily. Also look to see if the fact nodeID is just 7 bits was mentioned anywhere since that is no longer true either for a given floor. It now holds the full 8 bits value since it has inherited the floor in it and also simplifies the logic a bit

Piclib would surely need to be updated to support sending it all. New message types needed too.

Really just nice to have it time permits

Update code to use all PORTD and E ports too. Recheck all the pin assignments. Measure voltage again. CanRX and TX ports stay at B ports. Check MCLR too so it is not port E instead.

1. One model for can relay
   1.1. no status diode, just all outputs
2. One model for can switch - to be used by alarm system too
   2.1. 1 pin for input, 1 pin for diode status

Options: flash memory, EEPROM memory. Maybe flash could be used since this is really supposed to be constant (check datasheet on that again)

Even though we are talking about a theoretical case since this is unsigned long, so should be 2^32 quarters of a second, which is about 34 years:) But anyway in case anything ever goes wrong, cover the case of the quarter of a second getting to max and then move to 0 - the check of last switch press would effectively turn on the switch suppressing...

To save from future troubles and increase stability, drop the baud rate to say 10kbps or even less. Figure out if cansend in linux supports that though

Sometimes when the button is pressed, the input change is raised several times in a row, resulting in multiple CAN messages being sent and the target light blinking. Limit this, so that a CAN message is sent on switch press only after half a second after last switch press

no timer, think it over. perhaps disable the interrupt on first interrupt and then enable again till the CAN message is sent

Everything inside storage can be configured - think over the API inside data for that...

Right now just toggle is default. So create new datatype operation, treat toggle by default, but support switch on and off too. Most Likely will only need switch off all. That way we can have one smart such in wall to switch off all lights in the house. Or even combination. If a flag is set, treat input 1 as switch off all. Then we can just hook up this wall switch to existing smart CanSwitch in the hall for example.