First of all, I want to thank you very much for your help. I will try to provide you with as much information as possible.
I also found an example JSON file from the supplier. You can view it here. Maybe it’s interesting?
I found the following files, which I think might be useful: configuration.cfg, EmptyDbase.mdb, and Switcher (text document). Should I upload these files here? Would that be useful? Or is it better not to, since this might be sensitive information?
The input module is connected to regular push buttons, 24V potential-free push buttons, and motion detectors. The output module is mainly connected to light points and sunshade motors. So, it’s quite a simple system. The wiring runs via SVV.
All light points and motors are connected with relays. See the photo below. At the top, the L+N wiring from the motors or lighting is connected. At the bottom, the 24 volts (red) and the brown cable each go to the output module.
I have this complete list. I also have an MDB file where all the information is stored and can be opened in the software.
@IOT7712 You have been very helpful so far. You had some follow-up questions in this thread/topic. I have gathered as much information as possible. Would you have the time to review this again? Thank you in advance.
Hi, was 1,5D busy to figure this out.
1st wanted to try to directly control the output but didtn’t work.
Then tried pulse on input and I was able to control via a python script.
Like to share already a preview output, later on the script:
— Simulating push on input 11 —
PRESS: ff06250001010a37
<<< PRESS reply: ff04802500a9
RELEASE: ff06250000010a36
<<< RELEASE reply: ff04802500a9
KA_END: ff0525060080b0
<<< KA_END reply: ff16802500008068000000000000000000000000000000a3
Done. Check lamp/output 2 reaction.
So I am runnig a docker image python:slim and there I run the script:
#!/usr/bin/env python3
# Simuleer een korte druk op input 11 (triggert output 2)
import socket, time
HOST = "IP Alfaconnect"
PORT = 1470
# frames
VAR30 = bytes.fromhex("ff0531800a4000")
VAR31 = bytes.fromhex("ff0531c00a4040")
KA_REQ = bytes.fromhex("ff0525050080af")
KA_END = bytes.fromhex("ff0525060080b0")
# input press/release frames
SET_FRAME = bytes.fromhex("ff06250001010a37") # knop indrukken
CLEAR_FRAME = bytes.fromhex("ff06250000010a36") # knop loslaten
def send(sock, label, frame, delay=0.25):
print(f">>> {label}: {frame.hex()}")
sock.sendall(frame)
sock.settimeout(1.5)
try:
r = sock.recv(512)
if r:
print(f"<<< {label} reply: {r.hex()}")
else:
print(f"<<< {label}: (geen data)")
except socket.timeout:
print(f"<<< {label}: timeout")
time.sleep(delay)
def main():
print(f"Connecting to {HOST}:{PORT} ...")
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((HOST, PORT))
try:
send(s, "VAR30", VAR30)
send(s, "VAR31", VAR31)
send(s, "KA_REQ", KA_REQ)
print("\n--- Simulating push on input 11 ---")
send(s, "PRESS", SET_FRAME)
time.sleep(0.3) # korte druk
send(s, "RELEASE", CLEAR_FRAME)
send(s, "KA_END", KA_END)
print("Done. Check lamp/output 2 reaction.")
finally:
s.close()
if __name__ == "__main__":
main()```
Later on I will write (with help of chatgpt) a new script that will catch info from mqtt which sends which input to control. Later on I want to see if I can check a output status to have an idea if the output is enabled or not. This because later on I want to be able to check if the shutters are really running.
1 Like
Thanks a lot for sharing this — really appreciate the time and effort you’ve put into figuring it out and explaining it so clearly!
This is super helpful, and I’d be glad to assist wherever I can as you continue developing or testing the script.
Apologies for taking so long to get back to you. I see Kim has done some Python coding that goes along the lines you should proceed for integration.
I had a look at the photos you posted of the chips closeup and they seem to be mostly buffer chips on the IO boards and the smarts is in the controller (the bigger chip with the leading letter annoyingly obscured by a sticker, and a little too blurred to read in another photo)
As much as I distrust AI and the outdated slop it regurgitates, (most glaringly wrong in the fast moving world of HomeAssistant), it may be able to assist, as most combinations needed are a variation on a theme. Most of the command codes should be able to be sent and received in ‘ladder logic’ or ‘state machine’ style which has been well documented by the developer. Be sure to teach it the information and sample code in the attached pdfs for better code output. Be aware if the AI is guessing, and outputting garbage (expect it), your devices in the home may go crazy or burn out if rapidly or inappropriately switched. Allow a small time as well in your code for the controller to respond.
Go through each bit of code step by step to verify what it is doing. Focus on inputs first from switches, buttons, sensors etc is my recommendation and check what is received. Once it is right for one device type, the algorithm should work similarly for the rest, just with different addresses and commands as documented.
So far we’ve established that the serial interface (NetConnect module) was used to send and receive packets to the controller board via your LAN at IP Address 192.168.0.50 on port 1470 at 19200 baud, and the controller connects to each interface board via a bus, to drive individual buffered 24Volt DC input and output ports that are connected to the various devices in your home. This seems to be a straightforward wiring arrangement you should not need to touch. If it works, don’t fix it!
A full list of what devices are connected to each port and relay on the IO boards will possibly assist in defining entities in HomeAssistant, and matching them up with the codes needed to be sent (maybe bit patterns?) Make a table of device name, input or output, port number, code to trigger it, responses expected, and a pattern should emerge. You probably did that when it was being wired up in the first place. Is it the one in your JSON code, or found inside your Windows PC C:\AlfaStar folder files in some database file or text format?
Oops, I see you have already done this. I would be interested in seeing that list.
Check if there is sensitive stuff in there such as network passwords. Just local IP Addresses and what you have called device names shouldn’t matter as much as it is local to your house.
There are a lot of integrations in HACS that work on a similar basis, with send a code and listen to the response as their approach. MQTT may not be necessary - just write to the port and listen via the network and the HomeAssistant entitiy states. You basically have a giant lookup table for responses, and a one-to-one send-a-packet for each input change. If you are not skilled enough to write the code yourself from the documentation from the developer as well as the HomeAssistant guides to write integrations, you may be able to adapt an existing one for your needs, or get AI to pick up some clues to guide it. It’s Open Source - stand on the shoulders of giants, but don’t forget to attribute.
PS: Dom’t forget the checksums! Skip the STX preamble byte (0xFF) and add the rest of the bytes and stick it on the end.
Don’t forget the error codes as well and how you respond to them. This will have a big bearing on how robust your software integrates. Allow for clashes, overlapping receives as you are sending, high network traffic, and data corruption. Never forget the ‘or else’ clause at the bottom of any loop that you should never get to except for conditions you never anticipated.
The wiring already exists. Getting the logic correct to control it is most of your challenge. Wrapping a GUI around it comes later.
Keep us posted.
1 Like
IOT7712 en kimbo1st: Thank you for the detailed response. It took me a while to reply from my side, as I didn’t find the time earlier. My apologies.
Can I make this process easier by taking a new photo of the chip?
That’s already good news!
No problem :-). You can find the list attached. As you will see, I have three input modules and two output modules. The order in which they are connected determines whether they are a, b, or c. I haven’t included the dimmer module for now.
Would you know a good and comparable example? My knowledge is indeed limited, but I’m eager to learn and willing to spend some time on it. I would really like to find a solution.
Small update. I’ve managed to create an integration for now. Through this integration, I can read the status of the lighting and also control the lights. More info to follow…
1 Like
Current status. I can control all the lighting via Home Assistant, including a dimmer through a slider or via buttons (specific percentages). I also managed to control the sun shading. So that’s good news.
Good. Little steps on the way to full control.
Indeed. The foundation is now in place. From this point on, I can add additional features. ChatGPT was definitely not the solution for this. Claude.ai is much better at coding.
As iterated by most others already, for home assistant to be useful, it becomes part of the infrastructure and must work reliably, with minimal downtime or reboots. For many users, this is easier to accomplish by running it on a cheap/ dedicated/ low-power (x86_64) box (second hand thin-client (20-60 EUR is reasonable, as are 3-8 watts idle), alderlake-n n97/ n100/ n150, NUC, etc.). Given the inherent 24/7 nature, power consumption is key, details depend on local electricity prices and concurrent uses for other tasks (one server running at ~20-25 watts serving multiple important VMs can end up ahead than a flock of smaller systems at ~6 watts each, and most of them just marginal for their tasks in terms of performance). But this is distinctly different from ‘your old gaming rig’ with dedicated GPU (usually +30 watts on its own, without doing anything (and yes, local LLMs are changing that as well)) that will be more in the ~60+ watts range.
Obviously, if you already own a NAS (with virtualization features) or a small server, there’s no reason not to use that (just keep in mind that many of the smarthome rf protocols are implemented via USB connected devices, which does complicate virtualization and pass-through options - in many cases there are ethernet based alternatives to these, but usually higher priced or coming with other shortfalls (in their firmware)).
What generally doesn’t work for production usage, is running a VM on your desktop - not because of the hardware, but because of the vastly different usage approach (rebooting, hibernating, shutting off is common for a client, but always comes at the worst imaginable times for home assistant). You really need a system whose -uninterrupted- uptime is measured in weeks to months, for this to be viable - and that’s generally not a given on interactively used clients.
I’d still suggest to look at your local used markets for decommissioned thin-client like systems (Celeron j4xxx or better, ryzen embedded, alderlake-n, …), they are often surprisingly cheap, very low power consumption, passively cooled and neat & tidy; you might have to replace their SSD (32 GB official minimum, 64-128 GB provides more flexibility), 4 GB RAM usually works for starting. Their advantage is that they can pretty much be ‘forgotten’ about (with haos’ own update cadence being the only service interruption), while still providing USB ports for zigbee, bluetooth, z-wave, etc. pp.
Disclaimer: I have been using a haos VM on a dedicated low-power server under kvm for a long time (actually still do), and have been moving to a dedicated thin-client recently - not because of any issues with the virtualization, but because the host hardware of the server became a bit too limited (RAM, disk space) and upgrading that to comfortable levels (board&cpu, RAM-RAM-RAM, SSD) would have been more expensive (especially right now) than the thin-client.
Thanks for this useful information. I’m currently running Home Assistant on a Raspberry Pi, and I’m having no issues with it so far