Hello - I have been pouring over the amazing data provided here, and it’s a bit unclear to me whether the GT130 is needed in order to view data from the flow sensor, which is wired to the Sedna valve. I have the Sinope FS4220 plugged into the Sedna VA4220ZB. I added the valve directly to HA via ZHA and it was added no problem, and I can control it directly without the need for the neviweb bridge. But is there a way to see the flow meter, which is connected via the valve, without a Neviweb gateway (directly within HA)? I have added the template sensor which now shows up in my energy dash, but it isn’t pulling any data as I don’t think I can actually connect to the flow meter. Could you provide any clarity at all on this? Thank you for all the info so far!
The FS4220 with the GT130 report the flow level via the energy_kwh_count in L/hrs.
So in ZHA it should be via cluster 0xff01, attribute 0x0070 but as I don’t have the new sedna valve with flow meeter I can’t test it.
Can you dump all cluster/attributes from your valve. To do it just install ZHA toolkit and call the service
service: zha_toolkit.scan_device
data:
ieee: 50:0b:91:40:00:02:26:6d <-ieee of your valve
endpoint: 1
event_success: my_read_success_trigger_event
event_fail: my_read_fail_trigger_event
event_done: my_read_done_trigger_event
This will generate a file under config/scans with the name of your valve_scan_results.txt
It takes few minutes for the file to appear. Then send it to me via email.
Once we get the value we peobably need to divide by 1000 as the energy dash board use cubic meeter as value.
After checking in other device for energy_kw_count it should be
cluster 0x0702, attribute 0x0000 CurrentSummationDelivered (L/hr delivered)
For those interested I’ve created a ZHA quirks for the Sinopé 2nd gen Sedna valve with flow meeter.
To test you need to install my sinope-zha module and replace the file switch.py with the one from the branch sedna-flow-meeter
Let me know if it work so I can send a PR to ZHA-quirk
The Tank Level Monitor LM4110-ZB is finally released.
I utilize Zigbee2MQTT and don’t have any other Sinope devices. I have been waiting for this for awhile, since my Tank Utility stopped working. I am striving for all new devices to be cloud disconnected. This being said; so I don’t duplicate effort, is anyone else already working on the translations for Zigbee2Mqtt?
Yes I’m already adding it to ZHA and neviweb130 
Quirk for LM4110-ZB is available on my sinope-zha, file sensor.py
I’ve updated readme.md file to add the cluster/attributes specific to this monitor. Propane level is reported as gauge needle angle. To get it in % we need to do a calculation based on needle angle. To set an alarm at 20 or 30% tank capacity I’ve added the angle for both gauge type 5-95 and 10-80 with the cluster/attribute to read.
I’ll publish tonight a new release for neviweb130 to support this device as well.
Do you know if ZHA uses the common device list zigbee-herdsman-converters so other projects like Zigbee2MQTT will include it automatically as well?
If not, I know it can have a PR put it but I was just curious without have to dig thru ZHA since I don’t directly go that route myself.
Zigbee2MQTT use the zigbee-herdsman converter as part of there code but ZHA do not use this. If you need to dig out the cluster/attribute for the Sinopé zigbee devices just look in my sinope-zha module in the readme.md file. I know that zigbee-hurdsman guy are looking into it to update there cluster list for Sinopé devices. The other way is also true as I frequently compare what I have with zigbee-hurdsman.
Hi Claude, got my propane tank monitor installed today. Your quirk is being applied correctly by ZHA, and ZHA automatically detects outside temperature and battery level, but I am not getting any angle data. Should I temporarily connect the device to my spare GT130 to enable data reporting?
Also did you get the angles vs percentages values you describe. Reading attribute 0x0055 gives me a value of 49.0 with a full tank. Did Sinope give you a conversion table or did you scrape data from neviweb?
Hi, attribute 0x0055 should be activated for reporting. I’ve added in the readme.md the info for reporting. You can do it with zha-toolkit. For angle convertion to % it is a little special.
here is the calculation a do in neviweb130 which is almost the same as value reported by neviweb
def convert_to_percent(angle, low, high):
x = angle
x_min = 110
if low == 5:
x_max = 415
delta = 55
else:
x_max = 406
delta = 46
if delta <= x and x <= 70:
x = delta
if 0 <= x and x <= delta:
x = x + 360
y = (x - x_min) / (x_max - x_min)
lower_limit = low
upper_limit = high
value_range = upper_limit - lower_limit
pct = y * value_range + lower_limit
return round(pct)
If you have a 5-95 gauge, then low = 5, high = 95. For 10-80, low = 10, high = 80.
An angle below 55 for a gauge type 5-95 is equal to 95%
An angle below 46 for a gauge type 10-80 is equal to 80%
The calculation is a little different depending on your gauge type 5-95 or 10-80
I don’t know if I can add this calculation directly in zha or if we will need to create a template sensor for each type of gauge.
For my LM4110-ZB there was no reporting in zha but after I’ve connected it to neviweb to finalize integration in my neviweb130 component. I’ll revert it back to zha to check if the reporting was activated by Neviweb.
Sinopé never give data for there device but it is easy to get it from neviweb 
By the way the temperature reported by the LM4110-ZB is not directly the outside temperature. It is the device temperature but it is very close to the outside temperature as the LM4110-ZB do not produce a lot of heat.
In neviweb, the temperature is reported as OK and is not used by Sinopé. I’ve asked Sinopé to make that value available as it can be used as outside thermometer.
I have a few SP2610ZB’s and just curious if anyone has them working directly from HA using ZHA. I have them joining and they look like they are working, but the switch on/off that appears in HA only turns the led on and off. It does not switch the load. And yes I have the load plugged into the top outlet that is the swtiched one 
I tried adding them to habitat (which I am killing off) and the same behavior happened. I tried resetting them with the long/hold/push of the button and rejoining, but same behavior. Any ideas?
Hi @disruptivepatternmat, what happen when you just push de button on the device? Does the power come up on the controlled outlet ?
I’ve 7 SP2610ZB and three SP2600ZB on ZHA and all are working great. I did had a problem with on SP2610ZB that was keeping turning off and on after a certain amount of time. Sinopé replaced it without problem.
Probably the relay inside is not working properly.
All three of mine do NOTHING when I push the local button other than the led goes on and off - just like when I turn them on/of from HA. So I assumed I was doing something wrong - 1 might be a defect, 3 seems like “operator error” haha. I guess if there is nothing obvious or something I can do to reconfigure them or something, I’ll just return them 
Look like a hardware failure. But luckily you have a three years warranty with Sinopé. 
Just contact [email protected] and describe your problem. They will tell you what to do.
The replied that the top outlet is the only switched one and then never responded with a followup. So yeah I’m returning them…products are only as good as support.
Yes the top outlet is controlled by the switch and the bottom outlet is always on. Also the measured kilowatt is the total of both outlet. If you switch off the top outlet and you have something connected in the bottom one, the switch will display the energy used by the bottom outlet.
I can’t thank you enough for all this information Claude. I just got the Tank Level Monitor and am trying to integrate it with Home Assistant without neviweb. I’m looking over your Readme and am trying to setup the attribute reporting so I can see the angle.
Question: You list format in the reporting command, but there is no format in the zha_toolkit.conf_report service, only manf - which I assume is 4508 from your example.
I tried configuring at least the first 2 params in the monitor (unknown and remaining battery percentage) but the logs are showing failures on both
My monitor info
Monitor:
IEEE: 2c:11:65:ff:fe:a9:63:3e
Nwk: 0xed92
Device Type: EndDevice
LQI: Unknown
RSSI: Unknown
Last Seen: 2023-07-16T06:01:06
Power Source: Battery or Unknown
Quirk: sensor.SinopeTechnologiesLevelMonitor
and ZHA service I’m trying to call for battery
service: zha_toolkit.conf_report
data:
ieee: 2c:11:65:ff:fe:a9:63:3e
cluster: 0x0001
attribute: 0x0021
manf: 4508
min_interval: 0
max_interval: 65535
reportable_change: 1
tries: 3
event_success: zha_report_success_trigger_event
event_fail: zha_report_fail_trigger_event
event_done: zha_done
The log looks like it’s giving me the event fail due to UNSUPPORTED_ATTRIBUTE. Any thoughts?
2023-07-16 06:20:49.324 DEBUG (MainThread) [custom_components.zha_toolkit] event_data {'zha_toolkit_version': 'v0.9.5', 'zigpy_version': '0.56.2', 'zigpy_rf_version': '0.35.8', 'ieee_org': 2c:11:65:ff:fe:a9:63:3e, 'ieee': '2c:11:65:ff:fe:a9:63:3e', 'command': 'conf_report', 'command_data': None, 'start_time': '2023-07-16T10:20:48.223371+00:00', 'errors': [], 'params': {'cluster_id': 1, 'attr_id': 33, 'min_interval': 0, 'max_interval': 65535, 'reportable_change': 1, 'dir': 0, 'manf': 4508, 'tries': 3, 'expect_reply': True, 'args': [], 'event_success': 'zha_report_success_trigger_event', 'event_fail': 'zha_report_fail_trigger_event', 'event_done': 'zha_done', 'read_before_write': True, 'read_after_write': True}, 'success': False, 'result_conf': Configure_Reporting_rsp(status_records=[ConfigureReportingResponseRecord(status=<Status.UNSUPPORTED_ATTRIBUTE: 134>, direction=<ReportingDirection.SendReports: 0>, attrid=33)])}
2023-07-16 06:20:49.324 DEBUG (MainThread) [custom_components.zha_toolkit] Fire zha_report_fail_trigger_event -> {'zha_toolkit_version': 'v0.9.5', 'zigpy_version': '0.56.2', 'zigpy_rf_version': '0.35.8', 'ieee_org': 2c:11:65:ff:fe:a9:63:3e, 'ieee': '2c:11:65:ff:fe:a9:63:3e', 'command': 'conf_report', 'command_data': None, 'start_time': '2023-07-16T10:20:48.223371+00:00', 'errors': [], 'params': {'cluster_id': 1, 'attr_id': 33, 'min_interval': 0, 'max_interval': 65535, 'reportable_change': 1, 'dir': 0, 'manf': 4508, 'tries': 3, 'expect_reply': True, 'args': [], 'event_success': 'zha_report_success_trigger_event', 'event_fail': 'zha_report_fail_trigger_event', 'event_done': 'zha_done', 'read_before_write': True, 'read_after_write': True}, 'success': False, 'result_conf': Configure_Reporting_rsp(status_records=[ConfigureReportingResponseRecord(status=<Status.UNSUPPORTED_ATTRIBUTE: 134>, direction=<ReportingDirection.SendReports: 0>, attrid=33)])}
2023-07-16 06:20:49.325 DEBUG (MainThread) [custom_components.zha_toolkit] Fire zha_done -> {'zha_toolkit_version': 'v0.9.5', 'zigpy_version': '0.56.2', 'zigpy_rf_version': '0.35.8', 'ieee_org': 2c:11:65:ff:fe:a9:63:3e, 'ieee': '2c:11:65:ff:fe:a9:63:3e', 'command': 'conf_report', 'command_data': None, 'start_time': '2023-07-16T10:20:48.223371+00:00', 'errors': [], 'params': {'cluster_id': 1, 'attr_id': 33, 'min_interval': 0, 'max_interval': 65535, 'reportable_change': 1, 'dir': 0, 'manf': 4508, 'tries': 3, 'expect_reply': True, 'args': [], 'event_success': 'zha_report_success_trigger_event', 'event_fail': 'zha_report_fail_trigger_event', 'event_done': 'zha_done', 'read_before_write': True, 'read_after_write': True}, 'success': False, 'result_conf': Configure_Reporting_rsp(status_records=[ConfigureReportingResponseRecord(status=<Status.UNSUPPORTED_ATTRIBUTE: 134>, direction=<ReportingDirection.SendReports: 0>, attrid=33)])}
Hi @grammo, format is the data format returned for the report. You don’t need to put that information ZHA will know what to do with it when come the report data.
As for UNSUPPORTED_ATTRIBUTE: 134 it is attribute 0x0086 but I don’t understand from which cluster it comes. I’ll have to dig a little for this.
The LM4110-ZB could be slow to respond so maybe increasing the tries to more then 3 could help.
Today I’m going away from my desk so I’ll not be able to follow you for a couple of day. I’ll let you know when I’m back.
These steps were perfect when I was having trouble getting my Sinope TH1300ZB paired with Home Assistant running a SkyConnect on the Raspberry Pi. (I also enabled the experimental multi-protocol setting for the SkyConnect, but either way, those hard reset instructions were spot on.)