Hey @ejespinosa - I don’t use HA personally, so please take this with a grain of salt. From my understanding HA is deprecating support for legacy 32-bit CPU architectures. I think you’re using HA Green, which uses aarch64 (64-bit ARM), so you’re fine there. You shouldn’t have any problems using the API with this architecture.
I’m not sure why your latest comment got flagged by the community and hidden as it was a very valid, and helpful, response. I read it through the email and everything it said is very valid. I don’t see any reason why that wouldn’t work. You may be able to use something like ChatGPT to help you create the project.
I would say the hardest, and most critical, part about getting the Bluetooth going is what I call the “processor”. If you notice from several of the code examples in the API guide I reference what’s called the “CsBleProcessor”. This is the heart of the communication as it’s the bridge between the app and the firmware (aka the valve). The reason it’s critical is it keeps the connection alive, manages the packets, etc. Bluetooth radios have a supervision timeout of usually 5 seconds. This means that if there is no communication for 5 seconds, then the radio terminates the connection. This is needed so the radio doesn’t stay connected to something that is no longer there. Back in earlier Bluetooth radio (like the classic Bluetooth) they didn’t have this and if the app didn’t disconnect properly, then the radio would stay connected. The only way to get the radio to work again was to reboot the device to reset the radio. Also, I designed the keep-alive marco/polo when the valve is idle for this reason. It just let the firmware know the app is still there and communicating (and visa-versa). The process should handle all of this for you as well. Here is a 1,000 foot overhead of how it works:
Initial Setup / Shutdown
- Connect to the valve
- Once connected, start the processor loop
- This basically starts a thread, a timer, or anything else that continually loops to process events.
- Make sure you’re allowing the thread to sleep some after each loop!
- Process send / receive events for the life of the connection
- When the device disconnects, stop the processor
Receiving Packets
- When the firmware sends a packet, you should pass it to your processor so it can, well, process the packet.
- The process should determine if you received a status packet or a data packet
- Status Packet: If it’s a status packet, then it should be processed and nothing else needs to happen. For instance, if you receive a keep-alive marco, then you should respond with a polo. If you receive a NAK, then you should resend the last packet you just sent.
- Data Packet: If it’s a data packet, then you should verify it (see the guide) and then get the JSON data payload. Once you have the JSON payload, you can send that off to the app. Like, “hey app, I just received this data, here you go!”. The way I handle this is I keep a map of the data coming in. The key for the map is the packet key (see the guide again for these) and the value is the value for the key. When I parse all of the data, I send the map of changes. If you’re going to use Python, then see this on how to setup listeners (https://stackoverflow.com/questions/58554471/implementation-of-callback-or-listener-in-python). You could have a “OnBleDataPacket” callback. Then anything in your app that needs to receive that data, just set it up as a listener.
Sending
- Any time you need to send data to the valve you just need to have the process queue the packet. The queue will hold all pending packets to send to the valve.
- When the processor loops, it will check to see if there are any pending packets pending to be sent in that queue. If there is, and the processor is idle (aka it’s not already receiving or sending anything), then it will start the sending process.
- It should check to see if the packet needs “chunked” into smaller pieces. This is done by looking at the packet length and the MTU. If the packet doesn’t need chunked, then just send it (don’t forget to account for the header and CRC bytes!). If it’s large than the MTU, then it needs chunking into multiple smaller packets.
- Note that 99.9% of the time a single packet is sufficient, so you can probably keep it simple and just work with single packets. It’s not like you’re going to be sending graph data, error logs, etc. so it should be fine.
- Send each chunk to the valve
Of course that a very basic overview, but hopefully it gives you some kind of overview of how I handle it. If I get the time, I would like to create a non-official app that shows how to do this.
James, thank you for your reply. I have no idea either why they hid my previous message, since I thought it would be helpful.
Anyways, I just wanted to let you know I have received the new board and installed it. Even though it came with no instructions, I was able to figure that out. For someone who may be going through the same process, here are the board replacement instructions:
- Closed both water valves in the Softener tank
- Pull up carefully the transparent cover, making sure you don’t pull any cables. The clear plastic cover has some tabs at the bottom of the front and the back, pull out those tabs and the cover will come out easily.
- Once the clear cover has been taken out, the board is exposed. The board has two taps on the left and right side.
- Disconnect the DC power from the electrical transformer, and the battery back up going to the board
- Pull the board tabs slowly, and the board will come out.
- Once the board is out, take a picture of the other cable connections (besides the power) going to the board, that way you can check later if you get confused.
- Disconnect all connectors, get the new board, and put the existing connectors back into the new board
- Place the new board into the tabs holders
- Connect the DC power to the new board and put the clear cover back in place
- Start the Chandler App, the application will connect to the new board and it would prompt you automatically to update to the new 6.3 version
Very Simple! I was watching some videos from Home Assistant and it looks like it is a lot easier to use a Bluetooth Proxi rather than a Bluetooth Pin. So I have changed my mind in that sense, I have already the Bluetooth Proxy and waiting to get them to start playing with it.
James, I would have to read your directions calmly this week. I will keep you posted. Greetings,
Ernesto
2 Likes
@JamesDougherty thanks for putting together the repo. I’ve been working on talking to the device on linux via Rust. The guide has been helpful. However, I am hitting some issues. Happy to post these over on the Github repo or somewhere else if that works better.
I’m hitting an issues where every time I connect and try to auth and it fails I then have to unplug the device before I can talk to it again. Neither the iOS app or my Rust program can talk to it. I have tried sending the R before disconnect, but that doesn’t seem to help. Any idea what could be going wrong?
I also can’t seem to get auth to work. A token copied directly from the app results in {"as":1}.
Again, thanks for the guide. And if there is a better place to raise these issues, let me know.
Hey @grounded042, you’re more than welcome! I would open a ticket on GitHub as this will keep keep the HA thread clean and it will help separate out issues to make it easier for others to read.
With that being said, this is a known issue and one of the reasons I mentioned it as an important note (https://github.com/ChandlerSystems/Signature-API-Guide/blob/7ae579d141246d4bcd78c52ee12fe12d4801ec25/other-important-notes.md). I haven’t really looked into it because (a) other priorities and (b) once you get the communication working properly the valve will no longer do that (as you can see with Legacy View). I had this happen initially when I was developing our new app as well, but it no longer happens. So, this is known and an unfortunate side effect for now. It will stop doing it though once you get the kinks worked out.
As far as authentication goes, did you send the ID packet first? You have to the send the ID packet (byte 0xEA as a raw packet - no CRC, no JSON, etc.), wait for the ACK to come back from the valve (0xCC), and then you can send the token as the valve will be expecting the token at that point. Also, what does your token look like when you’re sending it? Do you have any logging? I would open an issue on GitHub and post that information there. I’ll get it worked out and help get it going for you.
On a side note, we’re closed tomorrow for the 4th and I’ll be out of town. I’ll also be out of state from the 19th thru the 29th. So, please bear with me if I can’t respond during those periods.
With that being said, I hope you have a great 4th!
Thanks! I’ll move things over to the repo (already opened one PR there 
).
Hey @lampshade29 - Sorry for the late reply, I was out of the office. The repo link for the guide is https://github.com/ChandlerSystems/Signature-API-Guide
1 Like
Hey @JamesDougherty, heads up that some of us have opened some issues on the repo. If you could take a look when you get a chance that’d be great
Thanks for the heads up, I didn’t get any notifications. I’ll double check the settings and go there now to have a look.
Is there a version of this for dummies? I have both the iron/sulfur filter and water softener, both on C6.16. I have no idea what I’m looking at in github, but would LOVE to get these integrated into home assistant.
Hello - We don’t have anything official yet and may not for a while. I would ask Jon (@grounded042) to see what he did. He has a pretty good grasp of it and, as far as I know, has created something.