Focus on delivering, not on hosting ceremonies.
The main idea of having a daily meeting (in a support / maintenance context) is to socialise what's being done and identify potential points of assistance between team members, but also to increase teamwork in general.
You did great by avoiding the "what I did yesterday, what I'll do today, any blockers" script. Based on my experience, it's great for a planned delivery routine but barely applies on projects like support / maintenance.
With that said, the standup should work as the team needs. Experiment. Agile is all about experimentation and constant improvement. Do the meeting twice a week. You could help identifying potential cases that could've been addressed quickly if there was a daily meeting.
During next retro, discuss about the experience and keep fine tunning.
Edit:
Whenever you have segregation of duties between people on the same team, is good to assess how useful is to have them in contact.
See challenges as opportunies:: In our case, we have DBAs, Unix and Bigdata experts. Each work is very specific into their area, however there's ocasionally common related tasks where they can work together. Even if the amount of shared work is low, it's still important to share a moment to create rapport. Besides, a healthy team should be willing to increase their T-Shaped skills, and having them shifting low complexity tasks is a very good way to flex some muscles on unexplored knowledge areas. In your case it's even better - having more people knowing more products is always beneficial. I'd just suggest to run away from the full stack developer, unless you're willing to invest dangerous bucks on your team.
However, if there's low engagement between parts, you may consider having standups separately (and reassess if there's a single team or not). Again, experiment > assess > rinse and repeat.